0% found this document useful (0 votes)

2K views464 pages

Rh362 7.4 Student Guide

Uploaded by

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

2K views464 pages

Rh362 7.4 Student Guide

Uploaded by

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 464

Join the explorers, builders, and individuals who boldly offer

new solutions to old problems. For open source, innovation is

only possible because of the people behind it.

STUDENT WORKBOOK (ROLE)

Red Hat Enterprise Linux 7.4 RH362
RED HAT SECURITY: IDENTITY
MANAGEMENT AND ACTIVE DIRECTORY
INTEGRATION
Edition 1

RH362-RHEL-7.4-en-1-20181003 Copyright ©2018 Red Hat, Inc.

RED HAT SECURITY:
IDENTITY
MANAGEMENT AND
ACTIVE DIRECTORY
INTEGRATION

RH362-RHEL-7.4-en-1-20181003 Copyright ©2018 Red Hat, Inc.

Red Hat Enterprise Linux 7.4 RH362
Red Hat Security: Identity Management and Active Directory
Integration
Edition 1 20181003
Publication date 20181003

Authors: Artur Glogowski, Chen Chang, Morgan Weetman, Razique Mahroua,

Victor Costea
Editor: Philip Sweany
Copyright © 2018 Red Hat, Inc.

The contents of this course and all its modules and related materials, including handouts to audience members, are
Copyright © 2018 Red Hat, Inc.

No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but
not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written permission of
Red Hat, Inc.

This instructional program, including all material provided herein, is supplied without any guarantees from Red Hat,
Inc. Red Hat, Inc. assumes no liability for damages or legal action arising from the use or misuse of contents or details
contained herein.

If you believe Red Hat training materials are being used, copied, or otherwise improperly distributed please e-mail
training@redhat.com or phone toll-free (USA) +1 (866) 626-2994 or +1 (919) 754-3700.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, Hibernate, 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 registered trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or
other countries.

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.

Contributors: Susan Lauber

Document Conventions vii

Introduction ix
Red Hat Identity Management and Active Directory Integration ...................................... ix
Orientation to the Classroom Environment .................................................................. xi
Internationalization ................................................................................................. xiv

1. Installing Red Hat Identity Management 1

Describing Red Hat Identity Management (IdM) ............................................................ 2
Quiz: Describing Red Hat Identity Management ............................................................ 9
Identifying Directory Service Needs ............................................................................ 11
Quiz: Identifying Directory Service Needs ................................................................... 15
Installing Red Hat Identity Management ..................................................................... 17
Guided Exercise: Installing Red Hat IdM ..................................................................... 23
Lab: Installing Red Hat Identity Management ............................................................. 26
Summary ............................................................................................................... 33

2. Centralizing Identity Management 35

Managing IdM Server Content .................................................................................. 36
Guided Exercise: Managing IdM Server Content .......................................................... 44
Managing IdM Clients ............................................................................................. 54
Guided Exercise: Managing IdM Clients ..................................................................... 66
Programming with the Management Interface ............................................................ 72
Guided Exercise: Programming with the Management Interface .................................... 78
Lab: Centralizing Identity Management ..................................................................... 86
Summary ............................................................................................................... 97

3. Authenticating Identities with Kerberos 99

Defining Kerberos Authentication ............................................................................ 100
Quiz: Introducing Kerberos Authentication ............................................................... 104
Configuring Hosts and Services for Kerberos ............................................................ 106
Guided Exercise: Configuring Hosts and Services for Kerberos ..................................... 109
Configuring Remote Kerberos Authentication ............................................................ 114
Guided Exercise: Configuring Remote Kerberos Authentication ..................................... 116
Managing the Kerberos Domain ............................................................................... 119
Guided Exercise: Managing the Kerberos Domain ...................................................... 122
Lab: Authenticating Identities with Kerberos ............................................................. 125
Summary .............................................................................................................. 131

4. Managing a Public Key Infrastructure 133

Describing the IdM Certificate Authority ................................................................... 134
Guided Exercise: Describing the IdM Certificate Authority ........................................... 136
Managing Certificates ............................................................................................ 140
Guided Exercise: Managing Certificates .................................................................... 143
Managing Secrets .................................................................................................. 152
Guided Exercise: Managing Secrets ......................................................................... 154
Customizing Authentication .................................................................................... 157
Guided Exercise: Customizing Authentication ............................................................ 160
Lab: Managing a Public Key Infrastructure ................................................................ 163
Summary .............................................................................................................. 173

5. Integrating IdM with Active Directory 175

Accessing Active Directory Using Direct Integration ................................................... 176
Guided Exercise: Accessing Active Directory Using Direct Integration ........................... 189
Accessing Active Directory Using A Trust Relationship ............................................... 199
Guided Exercise: Accessing Active Directory Using A Trust Relationship ....................... 209
Managing Active Directory Integration ..................................................................... 216
Guided Exercise: Managing Active Directory Settings ................................................ 230
Lab: Integrating IdM with Active Directory ................................................................ 237

RH362-RHEL-7.4-en-1-20181003 v
Summary .............................................................................................................. 241
6. Controlling User Access 243
Managing User Identities ....................................................................................... 244
Guided Exercise: Managing User Identities ............................................................... 247
Managing User Access .......................................................................................... 256
Guided Exercise: Managing User Access ................................................................... 261
Securing the Login Process ................................................................................... 265
Guided Exercise: Securing the Login Process ............................................................. 271
Managing IdM User Access Rules ............................................................................ 276
Guided Exercise: Managing IdM User Policies ........................................................... 282
Lab: Controlling User Access .................................................................................. 289
Summary ............................................................................................................. 297
7. Maintaining IdM Operations 299
Identifying the DNS Configuration .......................................................................... 300
Guided Exercise: Identifying the DNS Configuration .................................................. 308
Troubleshoot IdM Activities .................................................................................... 313
Guided Exercise: Troubleshooting IdM Activities ........................................................ 319
Lab: Maintaining IdM Operations ............................................................................ 323
Summary ............................................................................................................. 329
8. Integrating Red Hat Products With IdM 331
Configuring Roaming Home Directories ................................................................... 332
Guided Exercise: Configuring Roaming Home Directories ........................................... 335
Integrating Satellite 6 with IdM ............................................................................... 341
Guided Exercise: Integrating Satellite 6 with IdM ...................................................... 345
Integrating Ansible Tower with IdM ......................................................................... 349
Guided Exercise: Integrating Ansible Tower with IdM ................................................. 357
Lab: Integrating Red Hat Products With IdM ............................................................. 364
Summary ............................................................................................................. 372
9. Installing Scalable IdM 373
Describing IdM Topology ........................................................................................ 374
Quiz: IdM Topology ............................................................................................... 378
Building a Resilient IdM Topology ........................................................................... 380
Guided Exercise: Building a Resilient IdM Topology ................................................... 385
Configuring IdM Server Roles ................................................................................. 392
Guided Exercise: Configuring IdM Server Roles ......................................................... 399
Preparing for IdM Recovery ................................................................................... 409
Guided Exercise: Preparing for IdM Recovery ............................................................ 413
Lab: Installing Scalable IdM .................................................................................... 418
Summary ............................................................................................................. 423
10. Comprehensive Review 425
Comprehensive Review ......................................................................................... 426
Lab: Building An Active Directory Trust Relationship ................................................. 428
Lab: Building a Multi-Master IdM Topology ............................................................... 434
Lab: Manage Red Hat Identity Management .............................................................. 441

vi RH362-RHEL-7.4-en-1-20181003
DOCUMENT CONVENTIONS

REFERENCES
"References" describe where to find external documentation relevant to a subject.

NOTE
"Notes" are tips, shortcuts or alternative approaches to the task at hand. Ignoring a
note should have no negative consequences, but you might miss out on a trick that
makes your life easier.

IMPORTANT
"Important" boxes detail things that are easily missed: configuration changes that
only apply to the current session, or services that need restarting before an update
will apply. Ignoring a box labeled "Important" will not cause data loss, but may cause
irritation and frustration.

WARNING
"Warnings" should not be ignored. Ignoring warnings will most likely cause data loss.

RH362-RHEL-7.4-en-1-20181003 vii
viii RH362-RHEL-7.4-en-1-20181003
INTRODUCTION

RED HAT IDENTITY MANAGEMENT AND ACTIVE

DIRECTORY INTEGRATION
Red Hat Identity Management and Active Directory Integration (RH362)
provides the skills to configure and manage Red Hat Identity Management
(IdM), the comprehensive identity management solution bundled with Red
Hat Enterprise Linux. This course facilitates students to gain the Identity
Management skills most requested by customers:

• manage users using centralized domains

• create Active Directory trusts to share users in Windows and Linux
domains
• configure IdM as the integrated Identity Management back end for
multiple Red Hat products
• enhance Ansible configuration management using IdM user and group
information
• perform certificate management for services on Linux systems
• implement single sign-on and advanced login security methods
• manage user and domain security policies

COURSE • Implement identity and access management

OBJECTIVES solutions using Red Hat products in a Red Hat
Enterprise Linux and Microsoft Windows Server
environment.
• Implement secure access configurations,
including managing and troubleshooting
Kerberos, certificate servers and access control
policies.
• Integrate IdM as the back end for other Red Hat
enterprise products, including Satellite Server
and Ansible Tower.

Create and manage an scalable, resilient

Identity Management realm including both
Linux and Microsoft Windows clients and
servers.

AUDIENCE • Red Hat Certified System Administrators

(RHCSA) who wish to learn how to provision and
configure IdM technologies integrated with both
Linux and Windows systems and domains.
• Identity Management Specialists or Engineers
• Access Management Specialists or Engineers

RH362-RHEL-7.4-en-1-20181003 ix
Introduction

PREREQUISITES • The RHCSA certification is required; students

will utilize the full Linux security and
administration skill set.
• A Red Hat Certified Engineer (RHCE)
certification is recommended for additional,
essential HTTP and DNS service skills.

x RH362-RHEL-7.4-en-1-20181003
Introduction

ORIENTATION TO THE CLASSROOM

ENVIRONMENT

Figure 0.1: Classroom environment

In this course, the main computer system used for hands-on learning activities is workstation.
Eight other machines are also used by students for these activities: ad, client, idm, replica1,
replica2, satellite, tower, and utility. The ad machine is in the example.net DNS
domain. All other machines are in the lab.example.net DNS domain.

All student computer systems have a standard user account, student, which has the password
student. The root password on all student systems is redhat. The Active Directory domain
Administrator password on the Windows server is password123!.

Classroom Machines

MACHINE NAME IP ROLE

ADDRESSES

ad.example.net 172.25.250.13 Active Directory server

client.lab.example.net 172.25.250.11 RHEL system used as IdM client

idm.lab.example.net 172.25.250.8 RHEL Identity Management server

replica1.lab.example.net 172.25.250.9 RHEL IdM client, becomes replica server

replica2.lab.example.net 172.25.250.10 RHEL IdM client, becomes replica server

satellite.lab.example.net 172.25.250.7 Red Hat Satellite Server

RH362-RHEL-7.4-en-1-20181003 xi
Introduction

MACHINE NAME IP ROLE

ADDRESSES

tower.lab.example.net 172.25.250.12 Red Hat Ansible Tower server

utility.lab.example.net 172.25.250.14 RHEL server for NFS and other services

workstation.lab.example.com 172.25.250.254 Graphical workstation for student desktop

One additional function of workstation is that it acts as a router between the network that
connects the student machines and the classroom network. If workstation is down, other
student machines will only be able to access systems on the student network.

Several systems in the classroom provide supporting services. Two servers,

content.example.com and materials.example.com are sources for software and lab
materials used in hands-on activities. The classroom.example.com server is the NTP time
source for the classroom. Information on how to use these servers is provided in the instructions
for those activities.

Controlling Your Station

The top of the console describes the state of your machine.

Machine States

STATE DESCRIPTION

none Your machine has not yet been started. When started, your machine
will boot into a newly initialized state (the disk will have been reset).

starting Your machine is in the process of booting.

running Your machine is running and available (or, when booting, soon will be.)

stopping Your machine is in the process of shutting down.

stopped Your machine is completely shut down. Upon starting, your machine
will boot into the same state as when it was shut down (the disk will
have been preserved).

impaired A network connection to your machine cannot be made. Typically this

state is reached when a student has corrupted networking or firewall
rules. If the condition persists after a machine reset, or is intermittent,
open a support case.

Depending on the state of your machine, a selection of the following actions will be available to
you.

Machine Actions

ACTION DESCRIPTION

Start Station Start (power on) the machine.

Stop Station Stop (power off) the machine, preserving the contents of its disk.

xii RH362-RHEL-7.4-en-1-20181003
Introduction

ACTION DESCRIPTION

Reset Station Stop (power off) the machine, resetting the disk to its initial state.
Caution: Any work generated on the disk will be lost.

Refresh Refresh the page to reprobe the machine state.

Increase Timer Adds 15 minutes to the timer for each click.

The Station Timer

Your Red Hat Online Learning enrollment entitles you to a certain amount of computer time. To
help you conserve your time, the machines have an associated timer, which is initialized to 60
minutes when your machine is started.

The timer operates as a "dead man's switch," which decrements while your machine is running. If
the timer is winding down to 0, you can choose to increase the timer.

RH362-RHEL-7.4-en-1-20181003 xiii
Introduction

INTERNATIONALIZATION

LANGUAGE SUPPORT
Red Hat Enterprise Linux 7 officially supports 22 languages: English, Assamese, Bengali, Chinese
(Simplified), Chinese (Traditional), French, German, Gujarati, Hindi, Italian, Japanese, Kannada,
Korean, Malayalam, Marathi, Odia, Portuguese (Brazilian), Punjabi, Russian, Spanish, Tamil, and
Telugu.

PER-USER LANGUAGE SELECTION

Users may prefer to use a different language for their desktop environment than the system-
wide default. They may also want to set their account to use a different keyboard layout or input
method.

Language Settings
In the GNOME desktop environment, the user may be prompted to set their preferred language
and input method on first login. If not, then the easiest way for an individual user to adjust their
preferred language and input method settings is to use the Region & Language application. Run
the command gnome-control-center region, or from the top bar, select (User) → Settings.
In the window that opens, select Region & Language. The user can click the Language box and
select their preferred language from the list that appears. This will also update the Formats setting
to the default for that language. The next time the user logs in, these changes will take full effect.

These settings affect the GNOME desktop environment and any applications, including gnome-
terminal, started inside it. However, they do not apply to that account if accessed through an
ssh login from a remote system or a local text console (such as tty2).

NOTE
A user can make their shell environment use the same LANG setting as their
graphical environment, even when they log in through a text console or over ssh.
One way to do this is to place code similar to the following in the user's ~/.bashrc
file. This example code will set the language used on a text login to match the one
currently set for the user's GNOME desktop environment:

i=$(grep 'Language=' /var/lib/AccountService/users/${USER} \

| sed 's/Language=//')
if [ "$i" != "" ]; then
export LANG=$i
fi

Japanese, Korean, Chinese, or other languages with a non-Latin character set may
not display properly on local text consoles.

Individual commands can be made to use another language by setting the LANG variable on the
command line:

[user@host ~]$ LANG=fr_FR.utf8 date

jeu. avril 24 17:55:01 CDT 2014

xiv RH362-RHEL-7.4-en-1-20181003
Introduction

Subsequent commands will revert to using the system's default language for output. The locale
command can be used to check the current value of LANG and other related environment variables.

Input Method Settings

GNOME 3 in Red Hat Enterprise Linux 7 automatically uses the IBus input method selection
system, which makes it easy to change keyboard layouts and input methods quickly.

The Region & Language application can also be used to enable alternative input methods. In the
Region & Language application's window, the Input Sources box shows what input methods are
currently available. By default, English (US) may be the only available method. Highlight English
(US) and click the keyboard icon to see the current keyboard layout.

To add another input method, click the + button at the bottom left of the Input Sources window.
An Add an Input Source window will open. Select your language, and then your preferred input
method or keyboard layout.

Once more than one input method is configured, the user can switch between them quickly by
typing Super+Space (sometimes called Windows+Space). A status indicator will also appear in
the GNOME top bar, which has two functions: It indicates which input method is active, and acts
as a menu that can be used to switch between input methods or select advanced features of more
complex input methods.

Some of the methods are marked with gears, which indicate that those methods have advanced
configuration options and capabilities. For example, the Japanese Japanese (Kana Kanji) input
method allows the user to pre-edit text in Latin and use Down Arrow and Up Arrow keys to
select the correct characters to use.

US English speakers may find also this useful. For example, under English (United States) is the
keyboard layout English (international AltGr dead keys), which treats AltGr (or the right Alt)
on a PC 104/105-key keyboard as a "secondary-shift" modifier key and dead key activation key for
typing additional characters. There are also Dvorak and other alternative layouts available.

NOTE
Any Unicode character can be entered in the GNOME desktop environment if the
user knows the character's Unicode code point, by typing Ctrl+Shift+U, followed
by the code point. After Ctrl+Shift+U has been typed, an underlined u will be
displayed to indicate that the system is waiting for Unicode code point entry.

For example, the lowercase Greek letter lambda has the code point U+03BB, and can
be entered by typing Ctrl+Shift+U, then 03bb, then Enter.

SYSTEM-WIDE DEFAULT LANGUAGE SETTINGS

The system's default language is set to US English, using the UTF-8 encoding of Unicode as its
character set (en_US.utf8), but this can be changed during or after installation.

From the command line, root can change the system-wide locale settings with the localectl
command. If localectl is run with no arguments, it will display the current system-wide locale
settings.

To set the system-wide language, run the command localectl set-locale LANG=locale,
where locale is the appropriate $LANG from the "Language Codes Reference" table in this chapter.
The change will take effect for users on their next login, and is stored in /etc/locale.conf.

[root@host ~]# localectl set-locale LANG=fr_FR.utf8

RH362-RHEL-7.4-en-1-20181003 xv
Introduction

In GNOME, an administrative user can change this setting from Region & Language and clicking
the Login Screen button at the upper-right corner of the window. Changing the Language of
the login screen will also adjust the system-wide default language setting stored in the /etc/
locale.conf configuration file.

IMPORTANT
Local text consoles such as tty2 are more limited in the fonts that they can display
than gnome-terminal and ssh sessions. For example, Japanese, Korean, and
Chinese characters may not display as expected on a local text console. For this
reason, it may make sense to use English or another language with a Latin character
set for the system's text console.

Likewise, local text consoles are more limited in the input methods they support, and
this is managed separately from the graphical desktop environment. The available
global input settings can be configured through localectl for both local text
virtual consoles and the X11 graphical environment. See the localectl(1), kbd(4),
and vconsole.conf(5) man pages for more information.

LANGUAGE PACKS
When using non-English languages, you may want to install additional "language packs" to
provide additional translations, dictionaries, and so forth. To view the list of available langpacks,
run yum langavailable. To view the list of langpacks currently installed on the system,
run yum langlist. To add an additional langpack to the system, run yum langinstall
code, where code is the code in square brackets after the language name in the output of yum
langavailable.

REFERENCES
locale(7), localectl(1), kbd(4), locale.conf(5), vconsole.conf(5),
unicode(7), utf-8(7), and yum-langpacks(8) man pages

Conversions between the names of the graphical desktop environment's X11 layouts
and their names in localectl can be found in the file /usr/share/X11/xkb/
rules/base.lst.

LANGUAGE CODES REFERENCE

Language Codes

LANGUAGE $LANG VALUE

English (US) en_US.utf8

Assamese as_IN.utf8

Bengali bn_IN.utf8

Chinese (Simpliﬁed) zh_CN.utf8

Chinese (Traditional) zh_TW.utf8

French fr_FR.utf8

xvi RH362-RHEL-7.4-en-1-20181003
Introduction

LANGUAGE $LANG VALUE

German de_DE.utf8

Gujarati gu_IN.utf8

Hindi hi_IN.utf8

Italian it_IT.utf8

Japanese ja_JP.utf8

Kannada kn_IN.utf8

Korean ko_KR.utf8

Malayalam ml_IN.utf8

Marathi mr_IN.utf8

Odia or_IN.utf8

Portuguese (Brazilian) pt_BR.utf8

Punjabi pa_IN.utf8

Russian ru_RU.utf8

Spanish es_ES.utf8

Tamil ta_IN.utf8

Telugu te_IN.utf8

RH362-RHEL-7.4-en-1-20181003 xvii
xviii RH362-RHEL-7.4-en-1-20181003
CHAPTER 1

INSTALLING RED HAT IDENTITY

MANAGEMENT
GOAL Describe and install Red Hat Identity Management

OBJECTIVES • Describe IdM components and architecture

• Identify Directory service needs
• Install Red Hat Identity Management

SECTIONS • Describing Red Hat Identity Management (and

Quiz)
• Identifying Directory Service Needs (and Quiz)
• Installing Red Hat IdM (and Guided Exercise)

LAB Installing Red Hat Identity Management

RH362-RHEL-7.4-en-1-20181003 1
CHAPTER 1 | Installing Red Hat Identity Management

DESCRIBING RED HAT IDENTITY

MANAGEMENT (IDM)

OBJECTIVES
After completing this section, students should be able to:

• Describe the components and administrative functions of IdM

• Compare the supported and community versions of IdM

IDENTITY MANAGEMENT
Today, typical enterprise computing environments consist of hundreds or thousands of
interconnected computer systems, each running numerous applications and services, and
being accessed by a large and diverse set of local and remote users. Historically, user account
parameters, application permissions and security policies were configured using a diverse set of
protocols and utilities, such as Network Information Service (NIS), Kerberos, Lightweight Directory
Access Protocol (LDAP), sudo and TCP Wrappers. Each of these tools was locally managed and
separately administered.

Figure 1.1: Modern enterprise IT infrastructure model

Early computers stored user accounts in flat files on each system, requiring users to use separate
accounts to access each system. Unless sufficiently coordinated, a user's multiple accounts could
have different UIDs and passwords, complicating an administrator's ability to create consistent
access policies throughout the enterprise. A common method for creating consistent accounts and
policies on multiple systems was for administrators to copy account and policy configuration files
between systems in the enterprise, which was both tedious and error-prone.

Figure 1.2: Traditional model of storing users per application

In addition to the operating system's user account permissions and access controls, many
proprietary applications created their own additional sets of users and resource access controls,
stored in relational database structures or LDAP servers. Only more sophisticated application
designs shared the operating system's user accounts. Without an integrated solution, the growth of
systems and applications made user and policy management unsustainable.

2 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

Identity management solutions address this administrative ordeal by creating and configuring
users, systems, services and policies using centralized storage and a single set of tools built upon
existing, native Linux protocols and technologies. An Identity Management solution centralizes
identity management and identity policies, simplifying the administrative tasks involved, and
coordinating consistent user identity information, access control (authorizations) and related rules
and policies across one or more domains of computer systems.

An identity management system stores the information required for a user to authenticate to
different systems and applications. It also stores policy information the determines the resources
that a user is authorized to access. An identity management solution organizes by creating
domains, such that multiple machines share the configuration and resources of all the systems that
have joined the domain. Domain users sign in and authenticate to their domain only once and then
access other systems and resources and an administrator manages only one account for that user
across all the machines of the domain. Centralized management is scalable and sustainable, even
in very large organizations.

RED HAT IDENTITY MANAGEMENT

Red Hat Identity Management (IdM) was designed into Red Hat Enterprise Linux since RHEL 6.2,
to simplify identity management. The bundled IdM feature set provides an integrated identity
management service for a wide range of clients, including Linux, Mac, and Windows.

IdM implements identity and access management with central authentication management of
identities and security mechanisms, fine-grained access control policies, integrated Public Key
Infrastructure (PKI) services, two-factor authentication (2FA) support, cross-realm Kerberos trusts
with Active Directory (AD), and a feature for direct client connections to AD. Although IdM is not
an administrative tool for AD domains, IdM can also synchronize identities with AD. Depending on
the features that an administrator implements, IdM can facilitate the creation of Linux domains,
allowing Linux domain users to access both Linux and Windows resources, and Windows users to
access Linux resources.

IdM combines LDAP, Kerberos, DNS, and PKI protocols with a rich management framework, and
offers a powerful user interface for both web-based and command line administration. The primary
use for IdM is to provide identity services to Linux clients within enterprise environments using
these well established and open protocols, allowing Red Hat Enterprise Linux systems to serve as
Linux domain controllers. IdM is the Red Hat tuned and supported release of the upstream open
source FreeIPA project, built from popular Linux administration components including PAM, BIND
DNS, MIT Kerberos, and Dogtag PKI, integrated with the core 389 LDAP Directory Server.

Figure 1.3: Red Hat Identity Management architecture

The Red Hat Identity Management solution consists of a number of tightly integrated components.
While all of these services are included with IdM, not all are strictly required to be installed on
the IdM server, allowing some services to be installed on external servers and configured for
integration with the IdM domain:

RH362-RHEL-7.4-en-1-20181003 3
CHAPTER 1 | Installing Red Hat Identity Management

389 Directory Server (LDAP)

An open source LDAP directory server. It has a flexible schema that can be customized to
define entries for users, machines, network entities, physical equipment, buildings, and more.
It is used as the back end that stores data for other applications.

A directory server organizes stored information into the hierarchical structure of a directory
tree. The information structure consists of root entries (suffixes), intermediate or container
entries (subtrees or branches), and leaf entries (the actual data). 389 Directory Server trees
can be very complex, consisting of several branch points, or very simple (flat) with few branch
points. IdM uses 389 Directory Server as an LDAP back-end using a flat and simple directory
tree to store information related to user accounts, groups, services, policies, DNS zone and
host entries, and more.

MIT Kerberos
An authentication protocol that uses symmetric key cryptography to generate tickets that
authenticate users to network services. Kerberos-based authentication is safer than password-
based authentication. Passwords are never sent over the network, even when accessing
services on other machines. The Kerberos server is installed on the IdM domain controller, and
all Kerberos data is stored in the back-end Directory Server. Directory Server defines access
controls for stored Kerberos data. Because all Kerberos data is stored in IdM's Directory Server
back end, Kerberos server is managed through IdM tools.

Network Time Protocol (NTP)

NTP is used to synchronize clocks between systems over a network. A central server acts as an
authoritative clock, and clients referencing that NTP server synchronize their time to match.
Many IdM services require time synchronization to function correctly. For example, Kerberos
uses timestamped tickets to determine their validity. Whether the IdM server is acting as the
domain's NTP server, or the domain is relying on an external NTP server, time synchronization
is important to be successful before other time-sensitive services will work, such as password
expiration, ticket and certificate expiration, and account lockout. By default, IdM server acts as
the NTP server for the domain it hosts.

Domain Name Service (DNS BIND)

DNS is required for an IdM domain to ensure that clients are able to name resolve and contact
each other and the IdM server. Services, such as Kerberos, depend on host names to identify
their principal identities. DNS maps and resolves host names from and to IP addresses,
providing this service for client to obtain host name resolution. DNS is required to enroll new
clients in the IdM domain, locate the IdM servers within the domain, and locate all services and
clients within the domain. The IdM server installation creates DNS zone records that allow IdM
clients and servers to use DNS service discovery to find the LDAP and Kerberos servers (the
IdM servers) that are required for participation in the IdM domain. It is recommended to have
the IdM server also manage the DNS domain.

Dogtag Certiﬁcate System

Services and applications primarily use certificates for Transport Layer Security (TLS)
authentication and secure communication. Dogtag is included in IdM as a certificate authority
(CA). This CA issues certificates to resources within the IdM domain, such as replicas, hosts,
services, users and applications. Dogtag can be used as a root CA or it can have its policies
defined by an existing external root or intermediate CA.

The Dogtag Certificate System component also provides a Vault (Data Recovery Manager)
subsystem. A vault is a secure location for storing, retrieving, sharing, and recovering secrets.
A secret is security-sensitive data that should only be accessible by a limited group of people
or entities. For example, secrets include passwords, PINs and private SSH keys. Users and
services can access the secrets stored in a vault from any machine enrolled in the IdM domain.

4 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

RED HAT IDM BENEFITS AND FEATURES

IdM provides a rich, flexible, and well-documented command-line interface that simplifies
management of objects stored in the system. The web-based user interface is compatible with
mobile devices, while the command-line and web UI interfaces make it easy for an administrator to
centrally manage the Linux and UNIX systems in an IdM domain.

IdM in Red Hat Enterprise Linux allows customers to:

• Significantly simplify their Identity Management infrastructure.

• Can be configured to achieve compliance requirements like PCI DSS.
• Reduce the risk of unauthorized access or unauthorized privilege escalation.
• Create a foundation for the highly dynamic and scalable cloud and container capable operational
environment.
• Contribute to automated deployment of the new systems, VMs and containers with the
preconfigured identity, authentication and access control capabilities.
• Reduce the cost of day-to-day operation.
• Minimize investment into the underlying infrastructure.
• Improve user experience with enterprise-wide single-sign-on across heterogeneous
environments.
• Enable tighter application integration into the identity management fabric.
• Manage identity information and authentication credentials for users, services, systems and
devices.

Additional Active Directory integration benefits include:

• Linux clients are centrally managed via native Linux protocols and traditional means, such as
LDAP, Kerberos, and POSIX, for greater interoperability.
• Authentication, identity, and policy management in a central server for better compliance.
• Active Directory user authentication happens in Active Directory to meet audit requirements,
without requiring user or password synchronization.
• Management of Linux systems can be easily delegated to Linux administrators for a better
separation of duties and delegation of privileges.
• Each group controls its part of the infrastructure to reduce coordination time and costs.
• Reduced costs. The Linux environment can scale to address business needs without generating
additional costs, including those related to Client Access License (CAL) or third-party software.

Core features of IdM in Red Hat Enterprise Linux include:

• Authentication
• Kerberos- and LDAP-based password authentication.
• Kerberos based enterprise single-sign-on.
• Native or proxied OTP-based two-factor authentication.
• Certificate based authentication.
• Secure Shell (SSH) key-based authentication.
• Policy
• Fine-grained user- and group- based password policies.
• Centrally defined host-based access control.
• Centrally managed privilege escalation policies (sudo rules), SSH public keys, and Security-
Enhanced Linux (SELinux) user mappings.
• Flexible administrative model for delegation.
• Fine-grain read-write access control for all objects managed by the system.
• Manageability
• Simple installation scripts for server and client.
• Management of users, groups, hosts, host groups, netgroups, services, and SELinux users.
• Rich command-line and web-based user interface.
• Pluggable, extensible WebUI and CLI.
• User self-service, including password reset.

RH362-RHEL-7.4-en-1-20181003 5
CHAPTER 1 | Installing Red Hat Identity Management

•
Certificate provisioning and automatic renewal.
•
Automatic management of private user groups.
•
Easy password migration.
•
Automatic group membership for users and hosts.
•
Robust CA chaining tools.
•
Different sets of POSIX attributes and SSH keys for the same user accounts can be used on
different client systems.
• User life-cycle management and integration with user provisioning systems.
• Robust disaster recovery tools.
• Application program interface (API) browser.
• Infrastructure
• Up to twenty servers with multimaster replication and flexible replication topologies.
• Interoperability with a broad set of Linux and UNIX clients.
• Integrated DNS server.
• Serving sets of automount maps to different clients.
• Ability to act as a NIS server for legacy systems.
• Central vault to store passwords, keys and other secrets.
• Kerberos KDC proxy.
• DNS Security Extensions (DNSSEC).

Using IdM as a gateway between Linux and Active Directory environments reduces IT costs and
increases productivity, letting complex deployments be performed rapidly to meet business needs.
Active Directory integration features:

• Users can access systems managed by IdM using their Active Directory user name and password.
• Users can access systems managed by IdM via SSH using either enterprise SSO (recommended),
SSH keys, or user names and passwords.
• Access control policies for users from Active Directory are stored and managed in IdM using the
group structure defined in Active Directory.
• POSIX attributes required for logging into Linux systems can be managed in three different
ways:
• Attributes can be stored and managed in Active Directory, so IdM servers can consult Active
Directory for additional attributes and cache this information locally.
• POSIX data can be created as needed by IdM servers and System Security Services Daemon
(SSSD) client components, eliminating the need for centralized POSIX data management.
• Active Directory user attributes can be manged in IdM, along with Active Directory account
objects, which is convenient when migrating from a NIS-based, LDAP-based solution or early
versions of IdM that did not support trusts.
• A single IdM forest can establish trusts with multiple Active Directory forests.
• Trusts can be one-way or two-way, although a two-way trust does not allow defined permissions
for IdM users in Active Directory domains.

FREEIPA
FreeIPA is the upstream open source community project for Identity Management. It is described
as an integrated security information management solution combining Linux (Fedora), 389
Directory Server, MIT Kerberos, NTP, DNS, and Dogtag Certificate System. It consists of a web
interface and command-line administration tools.

6 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

Figure 1.4: IPA components

FreeIPA is an integrated Identity and Authentication solution for Linux/UNIX networked

environments. A FreeIPA server provides centralized authentication, authorization and account
information by storing data about user, groups, hosts and other objects necessary to manage
the security aspects of a network of computers. FreeIPA is built on top of well known Open
Source components and standard protocols with a very strong focus on ease of management and
automation of installation and configuration tasks.

The Red Hat supported FreeIPA community is where the majority of the open source development,
idea maturation and component integration work takes place, using existing open source
components and tracking related open source development. The FreeIPA project was initiated
to try to solve existing difficulties in enterprise identity management, such as providing a
reliable open source alternative to existing solutions, creating a well-developed solution for
central management of Linux vital security information, and more easily providing access to the
information collect and managed, for better synchronization and analysis.

As an upstream project, Red Hat does not provide support for the FreeIPA community edition.
Instead, IdM is the tuned and integrated version for Red Hat Enterprise Linux, maintained
and support by Red Hat. Some upstream functionality may be tech preview for use in Red Hat
Enterprise Linux or only supported by the upstream project or on Fedora. The web UI may also look
different then the upstream version, as IdM will follow Red Hat's product branding designs.

Originally, the IPA in FreeIPA was designed to represent:

• Identity - manage Linux users and client hosts in a realm from one central location with CLI, Web
UI or extensible API access. Enable Single Sign On authentication for all systems, services and
applications.

• Policy - define Kerberos authentication and authorization policies for all identities. Control
services like DNS, SUDO, SELinux or autofs.

• Audit - methods for collecting and auditing security events, logs, and user activities, allowing
the ability to respond to noncompliance conditions to implement defined policies. However,
development of this component has been deferred.

RH362-RHEL-7.4-en-1-20181003 7
CHAPTER 1 | Installing Red Hat Identity Management

The FreeIPA community determined that developing an auditing solution was such a significant
effort that it would require a project of its own. They decided to focus on improving the identity and
authentication aspects of FreeIPA. In the mean time, the third area of focus for the FreeIPA project
has become trusts, instead of auditing:

• Trusts - create mutual trust with other Identity Management systems like Microsoft Active
Directory.

The community continues to monitor open source projects in the audit related space. The
Event Logging API (ELAPI) project was one result of this auditing evaluation. Another area of
development, the Centralized Logging project, is building a solution using centralized servers
based on Elasticsearch for data storage and searches, rsyslog/logstash/fluentd for log reception
and processing and Kibana for data display and dashboards.

REFERENCES
Further information about FreeIPA is available at the project page at:
FreeIPA
https://www.freeipa.org/page/Main_Page

Further information is available in the Introduction to Red Hat Identity Management

section in the Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and
Policy Guide at
https://access.redhat.com/documentation/en-US/index.html

Further information about the Event Logging API is available at

ELAPI
https://pagure.io/ELAPI

Further information about the Centralized Logging project is available at

Centralized Logging
https://www.freeipa.org/page/Centralized_Logging

8 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

QUIZ

DESCRIBING RED HAT IDENTITY

MANAGEMENT
Choose the correct answers to the following questions:

1. Which statement best describes Identity Management?

a. Identity Management decentralizes authentication procedures by moving user identity
information to flat files located on every Linux system.
b. Identity Management is a computer security term that defines the management
procedures for creating and maintaining DNS domains.
c. Identity Management is a set of tasks for controlling authentication and authorization of
users, applications, systems, or devices.
d. Identity Management is a remote automation task for controlling security logs.

2. Which two technologies are Red Hat Identity Management components? (Choose two.)
a. Active Directory
b. SMB
c. LDAP
d. SSH
e. NFS
f. Kerberos

3. In the upstream project, what are the three primary focus areas that FreeIPA
addresses? (Choose three.)
a. Identity
b. Policy
c. Audit
d. Trusts

4. Which two statements describe common use cases for Red Hat Identity Management?
(Choose two.)
a. A drop-in replacement for Active Directory forests in a heterogenous enterprise
environment.
b. A directory service and external namespace for identity management application
development.
c. A gateway between Linux LDAP and Active Directory that supports one-way and two-way
cross-forest trusts.
d. Centralized authentication management for users accessing client systems running a
Linux operating system.

RH362-RHEL-7.4-en-1-20181003 9
CHAPTER 1 | Installing Red Hat Identity Management

SOLUTION

DESCRIBING RED HAT IDENTITY

MANAGEMENT
Choose the correct answers to the following questions:

1. Which statement best describes Identity Management?

2. Which two technologies are Red Hat Identity Management components? (Choose two.)
a. Active Directory
b. SMB
c. LDAP
d. SSH
e. NFS
f. Kerberos

3. In the upstream project, what are the three primary focus areas that FreeIPA
addresses? (Choose three.)
a. Identity
b. Policy
c. Audit
d. Trusts

10 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

IDENTIFYING DIRECTORY SERVICE

NEEDS

OBJECTIVES
After completing this section, students should be able to:

• Compare the IdM bundle to the standalone products

• Describe directory server storage characteristics

• Describe master/replica directory relationships

• Describe the fundamental topology of IdM

SELECTING IDENTITY MANAGEMENT SOLUTIONS

Historically, multi-user systems stored user credentials in local flat files. Configuring identical user
authentication and authorization across multiple homogeneous systems required duplicating the
flat file entries to each system. This user management model was error-prone and scaled poorly.

Many different approaches are used to centralize and secure identification-related data in IT
environments. One approach is to use a database as a back end for storing identification-related
data. The database can be a relational database or a specific database that creates directories for
storing small pieces of information. These directories tend to be write-once/read-many systems,
while relational databases are often write-many/read-rarely systems. Special-purpose directories
are common in real life and on the Internet; in many ways, a directory is like a specialized database
or file system, because it stores many small pieces of information for search and retrieval. However,
unlike a file system, a directory is not optimized to deal with large random blocks of data, nor to
seek out a single random block of that data and retrieve it.

Typically, this type of directory is designed to store many small pieces of information, which are
frequently read or searched but rarely written to or updated. Individual entries tend to be based on
collections of common attributes, like phone numbers, names, and addresses, which are searched
frequently by many different users.

There are many different ways an organization may make use of a directory. A directory may be
used to store internal or external contact information, and could be accessed from network-capable
address book clients or other applications. A directory may also be used to centrally manage
user authentication information, such as usernames and passwords. It may be used to centrally
coordinate configuration files or other informational databases for network services. Or it may
simply store arbitrary data for later search and retrieval.

Lightweight Directory Access Protocol (LDAP)

Modern identity services store information in a non-relational directory tree structure, accessed
using an application protocol designed for efficient sharing of small amounts of typically static
data. The LDAP protocol was originally designed to be a subset of the X.500 Directory Access
Protocol (DAP), an early directory services project for email exchange and name lookups, which
developers found especially difficult to implement. The first LDAP server was used as a gateway
to an X.500 server, using only the lightweight DAP parameters specific to developers. Within a few
years, operators realized that 90% of the X.500 server activity was accessed through the LDAP
gateway, and X.500 was officially declared too complex, in favor of LDAP.

Today's IT world, with virtualization, cloud technology, microservices, and many communication
technologies, is more connected and focused on the idea of Everything as a Service (EaaS). Identity

RH362-RHEL-7.4-en-1-20181003 11
CHAPTER 1 | Installing Red Hat Identity Management

management solutions are changing to effectively deliver those services to users on-demand,
while securely determining who gets access to what service and to what degree. At the same time,
users of new and older technologies must be able to verify the identities of service providers that
manage the technologies.

Choosing the Right Identity Management Solution

There are a large number of identity management solutions available. When selecting a solution for
your organization, you should consider the following:

• the scope of your organization

• the required set of features your identity management solution needs to provide
• ease of deployment and integration with existing technologies
• scalability of the proposed solution
• cost of deployment and ownership

Choosing the right identity management system starts by defining information sources, such
as users of the system, the roles they hold in the organization, and the policies that define
how identity rules relate to resource access. Modern identity management is built on directory
services that function as repositories for data about the users and their identities. High availability,
or directory replication and optimized performance, are major requirements for an identity
management system to meet today's business needs.

Red Hat offers customers the freedom to choose between two products that can be used to build
an identity management system: Red Hat Identity Management (IdM) and Red Hat Directory Server
(RHDS). Whereas Red Hat Directory Server is a separate product, Red Hat Identity Management is
included in Red Hat Enterprise Linux.

COMPARING RED HAT IDENTITY MANAGEMENT (IDM)

TO RED HAT DIRECTORY SERVER (RHDS)
Comparing these two products will help you to identify a solution that best fits your business
needs.

Red Hat Directory Server (RHDS)

RHDS is a generic open source LDAP-based directory server designed for managing identities
in enterprise environments. It is a separate LDAPv3-compliant product, delivered as a separate
subscription. Among the features supported are four-way multi-master replication, scalability
to thousands of operations per second and tens of millions of entries stored, 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, and much more.

RHDS can be customized for a broad range of uses, but its typical use case is as a back-end
directory to store data for business applications that provide services on the Internet. It has a
flexible and customizable schema for entries such as users, machines, network devices, equipment,
or even buildings.

Typical use cases for RHDS include a back end for externally-facing applications with a large
volume of data, environments requiring a lot of schema customization, or a drop-in replacement
for an existing LDAP solution.

• General-purpose replicated identity storage

• Storage for user accounts as a back end for a business application
• High volume of read and authentication operations
• Distributed and complex topologies with replication and schema customization

12 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

It is not recommended to use RHDS outside its best-fit cases. For example, adopting RHDS to
manage internal identities and related policies would require additional resources. As Directory
Server, RHDS does not provide any system, policies, certificate, and key management capabilities
for inside the enterprise. Integration with Microsoft Active Directory using RHDS is only possible at
a very basic level.

Red Hat Identity Management (IdM)

Red Hat Identity Management (IdM) is a centralized and unified way to manage identity stores,
authentication, policies, and authorization policies in a Linux-based domain. IdM supports
advanced features of the Linux operating system, and native integration with Active Directory. IdM
is included with a Red Hat Enterprise Linux subscription without additional charge.

Using IdM provides administrators with the capability to:

• Maintain identities stored in one central place

• Apply policies to multiple machines at the same time
• Centrally manage privilege escalation with sudo rules.
• Define rules for mounting home directories
• Define different access levels for users by using host-based access control, delegation and other
rules
• Provide single sign-on so users can access multiple services and applications without repeatedly
being prompted for their credentials
• Integrate Linux systems with Microsoft Windows systems by establishing a relationship with an
Active Directory server
• A JSON-RPC-compatible API for managing the IdM server

The primary purpose of IdM is to manage identities and user authentication and authorization
policies that relate to those identities. The underlying directory server technology is the same for
both Red Hat Directory Server and IdM. However, IdM is optimized to manage identities. This limits
its general extensibility, but also brings certain benefits: simpler configuration, better automation
of resource management, and increased efficiency in managing identities.

NOTE
IdM is not a drop-in replacement for Active Directory. Both provide benefits
depending on the environment.

Red Hat Certificate System (RHCS) is another product included in IdM. Depending on the
organizational needs, customers can purchase a subscription for RHCS as a stand-alone product
to create a complex PKI infrastructure or use the IdM included capabilities to create a PKI
infrastructure for the Linux based domain. IdM's PKI system can operate as either a root certificate
authority or as an intermediate authority, integrating existing trust models.

TOPOLOGY FUNDAMENTALS
Continuous functionality of IdM services is vital for users who access resources. One of the
built-in solutions for accomplishing continuous functionality of the IdM infrastructure is the
ability to replicate the central directory. Depending on your needs, IdM allows placing additional
servers to reflect your enterprise organizational structure. Additional servers can be deployed
in geographically dispersed data centers. The benefit of this feature is the ability to shorten the
path between IdM clients and the nearest accessible server. It is a recommended practice to have
multiple IdM servers in every data center.

RH362-RHEL-7.4-en-1-20181003 13
CHAPTER 1 | Installing Red Hat Identity Management

REFERENCES
Further information is available in the Preparing for a Directory Server Installation
chapter in the Red Hat Directory Server Installation Guide at
https://access.redhat.com/documentation/en-us/red_hat_directory_server/

Further information is available in the Introduction to Red Hat Identity Management

chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

14 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

QUIZ

IDENTIFYING DIRECTORY SERVICE

NEEDS
Choose the correct answers to the following questions:

1. Which statement is true about Red Hat Identity Management?

a. IdM is a highly configurable set of components that creates a completely customized
certificate management system.
b. Red Hat Directory Server is built upon IdM and takes advantage of IdM's mature multi-
master replication support.
c. The underlying directory server technology is the same for both Red Hat Identity
Management and Red Hat Directory Server.
d. IdM's capabilities make it ideal as a back end for Internet-facing applications with a large
volume of data.

2. What are two beneﬁts of using Red Hat IdM over RHDS? (Choose two.)
a. High volume of authentication operations
b. Users can access multiple services and applications without repeatedly being asked for
their credentials
c. Scalability to thousands of operations per second and tens of millions of entries stored in
LDAP
d. LDAP schema extension and customization
e. Integration of Linux systems with Windows systems by establishing a relationship with an
Active Directory server

3. Which two statements about continuous functionality in IdM are true? (Choose two.)
a. IdM does not support more than three replica servers.
b. Although all IdM servers joined by a replication agreement receive updates, only the
original IdM server that was installed first is considered a master.
c. The ability to replicate the central directory is built in to IdM.
d. IdM replica servers can be deployed in geographically dispersed data centers.

RH362-RHEL-7.4-en-1-20181003 15
CHAPTER 1 | Installing Red Hat Identity Management

SOLUTION

IDENTIFYING DIRECTORY SERVICE

NEEDS
Choose the correct answers to the following questions:

1. Which statement is true about Red Hat Identity Management?

16 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

INSTALLING RED HAT IDENTITY

MANAGEMENT

OBJECTIVES
After completing this section, students should be able to:

• Describe prerequisites for standard and customized IdM installations.

• Describe the IdM installation and uninstallation process.

PREREQUISITES FOR INSTALLING AN IDM SERVER

Red Hat Identity Management (IdM) is a product created for users wanting to use Linux-native
tools to create identity stores, centralized authentication, domain control, authorization policies
for Kerberos and DNS services for all their Linux-based systems. IdM is included in every RHEL
system. This allows for configuring that system as a fully-functional domain controller that shares
centrally-managed Kerberos and DNS services with other servers and clients.

Hardware Recommendations
You must design and size your IdM topology before installing your first IdM server. The Red Hat
recommended practice is to install multiple, replicated servers for performance, redundancy, and
balanced data distribution. Early course chapters use a single non-redundant server, but a scalable,
replicated design is taught in a later chapter.

IdM stores information in cache, so proper RAM sizing is very important. Follow these rules to
determine how much RAM your server needs:

• An IdM server with 10,000 users and 100 groups requires a minimum of 3 GB RAM and 1 GB of
swap space.

• A server with more than 100,000 users and 50,000 groups requires a minimum of 16 GB RAM
and 4 GB of swap space.

A basic user or host entry with a certificate takes around 10 KB in size. For large deployments
consider increasing the available memory amount since much of the data is stored in the cache.

NOTE
For further information on the hardware requirements, consult the Linux Domain
Identity, Authentication, and Policy Guide listed in the references section.

System Requirements
Always install a new IdM server on a clean system without any existing DNS, Kerberos, or Directory
Server instances. When you first install a new IdM server, the installer backs up some system files
that it overwrites. That back up is placed in to /var/lib/ipa/sysrestore/ directory.

Another requirement is to disable the Name Service Cache Daemon (NSCD). The older Name
Service Cache Daemon (NSCD) used in earlier identity management solutions is replaced by
SSSD in IdM. The two daemons are mutually exclusive; ensure that NSCD is always disabled. IdM
uses SSSD to perform caching, and having both services available simultaneously might cause
unforeseen problems. For more information about how to avoid conflicts between NSCD and SSSD,
see the System-Level Authentication Guide available at https://access.redhat.com/documentation/
en-US/index.html.

RH362-RHEL-7.4-en-1-20181003 17
CHAPTER 1 | Installing Red Hat Identity Management

IMPORTANT
IdM hostname resolution libraries require that IPv6 is enabled at the kernel level.
You do not have to use IPv6 addresses, but the IPv6 stack must be enabled. IPv6
is enabled on a default RHEL 7 installation. When IPv6 protocol support is fully
disabled at the kernel level, IdM is not able to operate certain important plug-ins
in its LDAP server. These plug-ins are required for interoperability with Active
Directory.

Your server host for IdM must have properly configured DNS. It needs to properly resolve its name
using both forward and reverse DNS queries. Most IdM domain functions depend on DNS records,
including LDAP directory services, Kerberos, and Active Directory integration. This is extremely
important because once configured, your DNS domain and Kerberos domain name can not be
changed.

Here is how to verify proper hostname resolution settings:

Ensure that the host server name is a fully qualified domain name. To verify your server's host
name, issue the hostname command:

IMPORTANT
The hostname command output must not be localhost or localhost6. If this is the
case, use the hostnamectl set-hostname NEW_FQDN_NAME command to set
the proper fully qualified domain name for the host. Furthermore, the fully qualified
domain name must not resolve to the loopback IP address (127.0.0.1), but must
resolve to the server's public IP address.

Verify the server's IP address by issuing the ip addr show command. Using dig command,
verify the forward and reverse DNS configuration:

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

(...)
;; ANSWER SECTION:
demo.example.com. 3600 IN A 172.20.150.8
(...)
[root@demo ~]# dig -x 172.20.150.8
(...)
;; ANSWER SECTION:
8.150.20.172.in-addr.arpa. 3600 IN PTR demo.example.com.
(...)

IMPORTANT
Be very cautions when making manual modifications to the /etc/hosts file. Ensure
that the IdM server host name is not part of the localhost entry and that it properly
lists the IPv4 and IPv6 localhost entries for the host.

IdM uses a number of ports for communication with its services. Ensure that the following ports
are not blocked by the firewall: 80,443,389,636,88,464,53 (TCP) and 88,464,53,123 (UDP). All
the required by IdM ports are present in the firewalld service definition. To open those ports, you
can use firewall-cmd with the --add-service= with the name of the service, for example
freeipa-ldap for IdM with LDAP, or freeipa-ldaps for IdM with LDAPS, or both. Optionally,

18 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

the firewall-cmd --runtime-to-permanent command allows you to save the active

runtime configuration and overwrite the permanent rules.

NOTE
Run the firewall-cmd --add-service=dns command if using IdM and DNS.
The DNS service is not part of the rich rule service definitions for FreeIPA.

[root@demo ~]# firewall-cmd --add-service=freeipa-ldap --permanent

success
[root@demo ~]# firewall-cmd --add-service=freeipa-ldaps --permanent
success

IDM SERVER INSTALLATION

As IdM is included in a standard Red Hat Enterprise Linux subscription, there is not much you have
to do to use it. Before you can create your IdM instance, you need to install at least the ipa-server
package. Depending on your architecture, if you want IdM to manage a DNS server as well, you
have to install two additional packages to set up DNS. In both cases, all required packages can be
installed using the yum command. This example shows the installation of IdM package with the
additional DNS packages:

[root@demo ~]# yum install ipa-server ipa-server-dns

(...)
Transaction Summary
============================================
Install 2 Packages (+227 Dependent packages)

Total download size: 113 M

Installed size: 300 M
Is this ok [y/d/N]: y

There are a substantial number of dependencies that get installed along with the ipa-server
package. They include the 389-ds-base for the LDAP service and the krb5-server for the Kerberos
service, as well as IdM tools.

IdM Install Script

Once all of the required packages have been installed, you can create a new IdM instance. To do
that, run the ipa-server-install command. This launches the script interactively. At the
prompt, you are asked questions to help you set up a basic IdM instance. This helps you quickly set
up a basic IdM instance that does not make use of more advanced features like DNS management
or CA certification management.

The setup script creates a new instance of an IdM domain and configures all the required services
or policies:

• 389 LDAP Directory Server instance

• Kerberos key distribution center (KDC)
• Active Directory WinSync plug-in
• Certificate Authority (CA)
• Network time protocol daemon (ntpd)
• Apache (httpd)
• SELinux targeted policy
• Domain Name Service (DNS) - optionally

RH362-RHEL-7.4-en-1-20181003 19
CHAPTER 1 | Installing Red Hat Identity Management

Depending on your needs for the IdM domain, the setup process can be minimal, in which you
provide a small amount of information, or it can be very specific, with user-defined settings for
various parts of the IdM services. Should you have to create a customized IdM environment,
you can pass those configuration settings as arguments to the ipa-server-install script.
Using those arguments allows for a versatile configuration that can easily be scripted. With these
noninteractive arguments, you also have the ability to configure additional IdM settings that are
not used during the interactive installation mode. To access the full list of available options, consult
the ipa-server-install man page.

Selecting a CA Conﬁguration
Red Hat Identity Management comes with the Dogtag Certificate System CA. This integrated
certificate authority (CA) can be used to create all required certificates and keytabs used by users
or hosts in a domain.

By default, most of the IdM servers are installed with the integrated certificate system governed
by the Dogtag Certificate System (CA). Within the IdM domain, that CA uses a signing certificate
to create and sign all of the host and user certificates. On the IdM host itself, server certificates
are required for IdM's internal domain services to work properly. For example, the LDAP server and
Apache server (for the Identity Management web UI) require server certificates for establishing
secure connections with each other.

For the signing certificate to work, the CA certificate has to be signed by the CA that issued it.
There are two ways that a CA can sign the Dogtag Certificate System CA signing certificate:

• The default Identity Management configuration uses the Dogtag Certificate System to sign its
own certificate. There are no additional parameters or configuration steps required when the
ipa-server-install command is run. This type of configuration means that there is no
higher CA instance and that the IdM's Certificate System is its own root CA.

• The initial domain CA certificate is issued by a different, possibly externally-hosted CA. In this
type of configuration, the external CA is the root CA for your domain. The internal IdM CA is
subordinate to that external root CA, this means that attributes like the validity period are set
by the root CA. For using an external CA, there are two additional steps that must be performed:
submit the generated certificate request to the external CA, and then load the CA certificate and
issued server certificate to complete the setup.

On rare occasions, a third configuration is possible, consisting of the installation of IdM without a
certification authority. That particular configuration requires that all certificates used within the
IdM domain be created, uploaded, and renewed manually.

IMPORTANT
Choosing the proper CA requirements is crucial before the beginning of the
installation process. After creating the domain, it is not possible to change the CA
configuration.

Selecting a DNS Conﬁguration

The proper DNS configuration is required for nearly for all Identity Management domain functions.
IdM can manage its own DNS or use an existing DNS. When using an integrated DNS server, most
of the DNS record maintenance is automated. For configuring IdM with internal DNS, use the set-
up script with the configuration option --setup-dns specified. Similar to the basic IdM setup, the
DNS setup can either prompt for the required information, or the DNS information can be passed to
the script to allow an automatic or unattended setup process.

There are some DNS limitations that need to be considered before starting the IdM installation.
The integrated DNS server provided by IdM is not designed to be used as a general-purpose DNS

20 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

server. Its main function is to support IdM deployment and maintenance. It does not support some
of the advanced DNS features. It is strongly recommended to use the integrated DNS for basic
usage within the IdM deployment. An IdM with integrated DNS enables the automation of some
DNS record management using native IdM tools.

When you choose to configure the IdM server with the internal DNS, two additional pieces of
information are required: whether to use any DNS forwarder and whether to use reverse DNS.

To perform the noninteractive installation, you can pass this additional information using the --
forwarder or --no-forwarders option.

The script always configures reverse DNS along with DNS, so it is not necessary to use any option
to enable reverse DNS, however, if you want to disable reverse DNS, use the --no-reverse.

To use an external DNS server, you must manually perform the following:

• Create the new domain on the external DNS server.

• Manually populate the new domain with records from the zone file generated by the IdM
installer.

• Update these records any time you install or remove a replica.

• Update the records after any changes in the service configuration, such as when an Active
Directory trust has been configured.

Managing NTP
Network Time Protocol (NTP) is used to synchronize clocks over the network. A central server acts
as an authoritative clock, and all of the clients referencing that NTP server synchronize their time
to match.

IMPORTANT
Many IdM services require time synchronization; for example, Kerberos uses
timestamped tickets to determine their validity.

An IdM server that acts as the NTP server for a domain synchronizes time and date before any
other operations can be performed. This operation is essential for other time or date related
services, such as password expiration, ticket and certificate expiration, or account lockout, to
function. IdM server works as the NTP server for the hosted domain. Other NTP sources can also be
used for the hosts.

IDENTITY MANAGEMENT SERVER INSTALLATION

The following steps outline the process for configuring an installation of Red Hat Identity
Management.

1. Display the syntax of ipa-server-install using its -h option.

2. Review the BASIC OPTIONS section of the ipa-server-install man page. Locate the
options for specifying the hostname and IP address of the IdM server. Locate the option
to set the password for the IdM admin user. Locate the option that allows for unattended
installation.

3. Review the Kerberos options. Locate the option for specifying the Kerberos realm. Locate the
option setting the Kerberos master password.

4. Review the DNS OPTIONS section of the ipa-server-install man page. Locate the
options that enables integrated DNS server. Locate the options related to reverse zones.

RH362-RHEL-7.4-en-1-20181003 21
CHAPTER 1 | Installing Red Hat Identity Management

5. Review the options for configuring NTP service.

6. Review the CERTIFICATES SYSTEM OPTIONS section of the ipa-server-install man page.
Locate the option which enables the use of an external Certificate Authority.

7. Review the options related the directory services.

8. Perform an interactive installation of IdM server on the idm host with integrated DNS and NTP
service.

9. After the installation is complete, validate the Kerberos, DNS, and NTP services and also verify
that you can log in successfully to the Red Hat Identity Management web user interface.

UNINSTALLING IDM SERVER

Uninstalling an IdM server instance is fairly simple. To do it, you need to issue two commands and
modify the DNS records that pointed to the name of the server that was running IdM:

1. Using a different server than the IdM (you can use one of the IdM clients), issue the ipa
server-del command to delete the desired IdM server from the topology:

[root@server1 ~]# ipa server-del demo.example.net

2. On the IdM server (demo.example.net, in this example), issue the ipa-server-install --

uninstall command:

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

3. Remove all nameserver (NS) DNS records pointing to the IdM server from all of your DNS
zones.

Optionally, if a replication topology is present, remove the topology segment that joins the server,
then delete the server.

IMPORTANT
If your web browser issues a warning that the IdM server's certificate serial number
conflicts with the one from the previous IdM server installation, delete the saved
certificates. If you are using Firefox, access the preferences and click the Advanced
button to select the certificate from the previous installation and delete it.

REFERENCES
Further information is available in the Installing Identity Management chapter in the
Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

22 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

GUIDED EXERCISE

INSTALLING RED HAT IDM

In this exercise, you will perform a minimal install of Red Hat IdM and explore its web
interface.

OUTCOMES
You should be able to:

• Perform a minimal installation.

• Explore the product interface and features.

1. Ensure that the firewalld service is enabled and running.

[root@idm ~]# systemctl is-enabled firewalld

enabled
[root@idm ~]# systemctl is-active firewalld
active

2. Use the firewall-cmd command to allow access for the freeipa-ldap and freeipa-
ldaps services.

[root@idm ~]# firewall-cmd --add-service=freeipa-ldap

success
[root@idm ~]# firewall-cmd --add-service=freeipa-ldaps
success
[root@idm ~]# firewall-cmd --add-service=freeipa-ldap --permanent
success
[root@idm ~]# firewall-cmd --add-service=freeipa-ldaps --permanent
success

3. Verify the hostname of the system. Ensure that the hostname is in FQDN format.

[root@idm ~]# hostname

idm.lab.example.net

4. Verify the IPv4 DNS configuration for the system. Ensure that the system has forward and
reverse DNS entries.

[root@idm ~]# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

RH362-RHEL-7.4-en-1-20181003 23
CHAPTER 1 | Installing Red Hat Identity Management

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 52:54:00:00:fa:08 brd ff:ff:ff:ff:ff:ff
inet 172.25.250.8/24 brd 172.25.250.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe00:fa08/64 scope link
valid_lft forever preferred_lft forever
[root@idm ~]# dig +short idm.lab.example.net A
172.25.250.8
[root@idm ~]# dig +short -x 172.25.250.8
idm.lab.example.net.

5. Verify that the necessary IPv4 host entry exists in the /etc/hosts file. Ensure that there is
an entry mapping the idm.lab.example.net host to its IP address, 172.25.250.8.

[root@idm ~]# grep -w $(hostname) /etc/hosts

172.25.250.8 idm.lab.example.net idm

6. Install the ipa-server package.

[root@idm ~]# yum install ipa-server ipa-server-dns

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

7. Perform an unattended installation of Red Hat IdM Server by executing the ipa-server-
install command with the --unattended option. Use the --realm, --ds-password,
--admin-password options to define the Kerberos realm, the Directory Manager
password, and the IdM administrator password, respectively. Lastly, use the --no-ntp
option to disable configuration of NTP.

[root@idm ~]# ipa-server-install --realm LAB.EXAMPLE.NET \

--ds-password RedHat123^ \
--admin-password RedHat123^ \
--no-ntp --unattended

The log file for this installation can be found in /var/log/ipaserver-install.log

==============================================================================
This program will set up the IPA Server.
...output omitted...
Be sure to back up the CA certificates stored in /root/cacert.p12
These files are required to create replicas. The password for these
files is the Directory Manager password

24 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

8. Log in to the Red Hat IdM web interface at https://idm.lab.example.net.

Authenticate as the admin user with the password RedHat123^.
8.1. From workstation, open the Firefox web browser and connect to https://
idm.lab.example.net.
8.2. You will encounter a certificate warning since the IdM Server is using a self-signed
certificate. Click Advanced, and then click Add Exception. Click Confirm Security
Exception to accept the self-signed certificate.
8.3. Enter admin in the Username field and RedHat123^ in the Password field. Click
Login to log in to the Red Hat Identity Management web interface.

9. Browse the sections of the web user interface for the management of users, groups, and
policies.
9.1. Click on the Identity tab. Then click on the Users and Groups tabs to familiarize
yourself with the interface for user and group administration.
9.2. Click on the Policy tab. Note the tabs for managing host-based access control, sudo,
SELinux user maps, passwords, and Kerberos tickets.

10. Click Administrator and then Logout to log out of the Red Hat Identity Management web
interface.

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 25
CHAPTER 1 | Installing Red Hat Identity Management

LAB

INSTALLING RED HAT IDENTITY

MANAGEMENT

PERFORMANCE CHECKLIST
In this lab, you will perform and customize an interactive installation of a Red Hat IdM Server.

OUTCOMES
You should be able to:

• Uninstall a single system IdM server.

• Install an IdM server with a custom configuration.

You must complete the previous exercise before starting this exercise.

Log in to workstation as student using student as the password. Run the lab idm-review
setup command to ensure that the IdM environment is running.

[student@workstation ~]$ lab idm-review setup

Log into the idm host as the student user. Use the sudo -i command to escalate privileges.

Uninstall the IdM server running on idm.lab.example.net. Since this is the only system in the
Kerberos realm, there is no need to remove the server from the topology prior to executing the
uninstallation.

Perform an interactive installation of Red Hat IdM on idm.lab.example.net. Configure the

installation so that DNS, NTP, and user home directories are enabled. DNS should be configured
without any forwarders.

Configure LAB.EXAMPLE.NET as the name for the new Kerberos realm. Set the password for the
Directory Manager to RedHat123^. Set the password for the IdM administrator to RedHat123^.

Configure NTP to only use the classroom.example.com server as a time source.

Once you have installed Red Hat IdM, verify the installation by logging into its web interface as the
IdM administrator.
1. Uninstall the previous installation of IdM server.
2. Configure the firewall to allow the services required by Red Hat IdM.
3. Verify the hostname of the system.
4. Verify the IPv4 DNS configuration for the system.
5. Verify that the necessary IPv4 host entry exists in the /etc/hosts file.
6. Perform an interactive installation of Red Hat IdM Server. Customize the installation to
achieve the desired configuration.
7. Configure NTP to only use the classroom.example.com server as a time source.

26 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

8. Log in to the Red Hat Identity Management web interface at https://

idm.lab.example.net. Authenticate as the admin user with the password RedHat123^.

Evaluation
From workstation, run the lab idm-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab idm-review grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 27
CHAPTER 1 | Installing Red Hat Identity Management

SOLUTION

INSTALLING RED HAT IDENTITY

MANAGEMENT

PERFORMANCE CHECKLIST
In this lab, you will perform and customize an interactive installation of a Red Hat IdM Server.

OUTCOMES
You should be able to:

• Uninstall a single system IdM server.

• Install an IdM server with a custom configuration.

You must complete the previous exercise before starting this exercise.

Log in to workstation as student using student as the password. Run the lab idm-review
setup command to ensure that the IdM environment is running.

[student@workstation ~]$ lab idm-review setup

Log into the idm host as the student user. Use the sudo -i command to escalate privileges.

Perform an interactive installation of Red Hat IdM on idm.lab.example.net. Configure the

installation so that DNS, NTP, and user home directories are enabled. DNS should be configured
without any forwarders.

Configure LAB.EXAMPLE.NET as the name for the new Kerberos realm. Set the password for the
Directory Manager to RedHat123^. Set the password for the IdM administrator to RedHat123^.

Configure NTP to only use the classroom.example.com server as a time source.

Once you have installed Red Hat IdM, verify the installation by logging into its web interface as the
IdM administrator.
1. Uninstall the previous installation of IdM server.
From the IdM server, as the root user, execute the ipa-server-install command with
the --uninstall option. Answer yes to confirm the uninstall procedure.

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

This is a NON REVERSIBLE operation and will delete all data and configuration!
It is highly recommended to take a backup of existing data and configuration using
ipa-backup utility before proceeding.

28 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

Are you sure you want to continue with the uninstall procedure? [no]: yes
----------------------------------------
Deleted IPA server "idm.lab.example.net"
----------------------------------------
Shutting down all IPA services
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa-custodia
Unconfiguring ipa-otpd
Removing IPA client configuration
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/
sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Systemwide CA database updated.
Client uninstall complete.
The ipa-client-install command was successful

2. Configure the firewall to allow the services required by Red Hat IdM.
2.1. Ensure that the firewalld service is enabled and running.

[root@idm ~]# systemctl is-enabled firewalld

enabled
[root@idm ~]# systemctl is-active firewalld
active

2.2. In addition to previously allowed services, allow the dns services through the firewall.

[root@idm ~]# firewall-cmd --add-service=dns

success
[root@idm ~]# firewall-cmd --add-service=dns --permanent
success

3. Verify the hostname of the system.

Ensure that the hostname is in FQDN format.

[root@idm ~]# hostname

idm.lab.example.net

4. Verify the IPv4 DNS configuration for the system.

Ensure that the system has forward and reverse DNS entries.

[root@idm ~]# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

RH362-RHEL-7.4-en-1-20181003 29
CHAPTER 1 | Installing Red Hat Identity Management

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 52:54:00:00:fa:08 brd ff:ff:ff:ff:ff:ff
inet 172.25.250.8/24 brd 172.25.250.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe00:fa08/64 scope link
valid_lft forever preferred_lft forever
[root@idm ~]# dig +short idm.lab.example.net A
172.25.250.8
[root@idm ~]# dig +short -x 172.25.250.8
idm.lab.example.net.

5. Verify that the necessary IPv4 host entry exists in the /etc/hosts file.
Ensure that there is an entry mapping the idm.lab.example.net host to its IP address,
172.25.250.8.

[root@idm ~]# grep -w $(hostname) /etc/hosts

172.25.250.8 idm.lab.example.net idm

6. Perform an interactive installation of Red Hat IdM Server. Customize the installation to
achieve the desired configuration.
6.1. Execute the ipa-server-install command. Use the --realm, --ds-password,
and --admin-password options to define the Kerberos realm, the Directory Manager
password, and the IdM administrator password, respectively.
Use the --setup-dns, --no-forwarders, and --mkhomedir options to
enable the desired features. The --mkhomedir option allows the creation of
user home directories. Specify the reverse DNS zone using the --reverse-
zone=250.25.172.in-addr.arpa. option.

[root@idm ~]# ipa-server-install --realm LAB.EXAMPLE.NET \

--ds-password RedHat123^ --admin-password RedHat123^ \
--setup-dns --no-forwarders --mkhomedir \
--reverse-zone=250.25.172.in-addr.arpa.

6.2. When prompted, accept the default host name configuration.

Server host name [idm.lab.example.net]: [ENTER]

6.3. When prompted, accept the default domain name configuration.

Please confirm the domain name [lab.example.net]: [ENTER]

6.4. When prompted, review and proceed with the proposed configuration for Red Hat IdM
by entering yes.

The IPA Master Server will be configured with:

Hostname: idm.lab.example.net
IP address(es): 172.25.250.8

30 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

Domain name: lab.example.net

Realm name: LAB.EXAMPLE.NET

BIND DNS server will be configured to serve IPA domain with:

Forwarders: No forwarders
Forward policy: only
Reverse zone(s): No reverse zone

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

7. Configure NTP to only use the classroom.example.com server as a time source.

7.1. Open the /etc/ntp.conf file and configure NTP to only use the
classroom.example.com server as a time source.

[root@idm ~]# vim /etc/ntp.conf

...output omitted...
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server classroom.example.com iburst

...output omitted...

Restart the NTP service.

[root@idm ~]# systemctl restart ntpd

NOTE
Running an NTP server on an IdM server installed on a virtual machine can lead to
inaccurate time synchronization in some environments. To avoid potential problems
in the course environment the IdM server will synchronize time with the same time
source as the Active Directory server.

8. Log in to the Red Hat Identity Management web interface at https://

idm.lab.example.net. Authenticate as the admin user with the password RedHat123^.
8.1. From workstation, open the Firefox web browser and connect to https://
idm.lab.example.net.
8.2. You will encounter a warning that the IdM server's certificate serial number conflicts
with the one from the previous IdM server installation. Go into Firefox's Preferences
settings. Click Advanced and select Certificates. Click the View Certificates button. In
the Certificate Manager window, click the Servers tab. Scroll down to the certificate
with the name, idm.lab.example.net. Highlight the certificate and then click
Delete to delete it. Click OK to confirm. Close the Certificate Manager window.
8.3. Still in Firefox's Preferences settings, click Privacy, and then click the link clear
your recent history. In the Time range to clear menu, select Everything, and
then click Clear Now. Close the Preferences tab to exit and then close the Firefox
browser.
8.4. From workstation, open the Firefox web browser and reconnect to https://
idm.lab.example.net. You will encounter a certificate warning since the IdM

RH362-RHEL-7.4-en-1-20181003 31
CHAPTER 1 | Installing Red Hat Identity Management

Server is using a self-signed certificate. Click Advanced, and then click Add Exception.
Click Confirm Security Exception to accept the self-signed certificate.
8.5. Enter admin in the Username field and RedHat123^ in the Password field. Click Login
to log in to the Red Hat Identity Management web interface.
8.6. Click Administrator and then Logout to log out of the Red Hat Identity Management
web interface.

Evaluation
From workstation, run the lab idm-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab idm-review grade

This concludes the lab.

32 RH362-RHEL-7.4-en-1-20181003
CHAPTER 1 | Installing Red Hat Identity Management

SUMMARY

In this chapter, you learned:

• Red Hat offers customers two product choices for building an identity management
environment: RHEL-integrated Red Hat Identity Management (IdM) and standalone Red Hat
Directory Server (RHDS).

• IdM utilizes the advanced features of the Linux operating system and provides native trust
integration with an Active Directory server. IdM is bundled with a Red Hat Enterprise Linux
subscription without additional charge.

• Red Hat recommends installing multiple, replicated servers to ensure performance, redundancy,
and balanced data distribution.

• An IdM server that acts as NTP server for a domain, synchronizes time and date before any other
operations can be performed. This operation is essential for other time or date related services,
such as password expiration, ticket and certificate expiration, or account lockout, to function. IdM
server works as the NTP server for the hosted domain.

RH362-RHEL-7.4-en-1-20181003 33
34 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2

CENTRALIZING IDENTITY
MANAGEMENT
GOAL Explain the services running on an IdM server,
discuss IdM clients, configure roaming home
directories, and explain the IdM REST API.

OBJECTIVES • Manage centralized Identity Management

content in a newly-installed IdM environment.
• Implement Identity Management clients in an
enterprise environment using both manual and
automated methods.
• Connect to IdM services through an API useful
for administrative scripting and automation.

SECTIONS • Managing Server Content (and Guided Exercise)

• Managing Clients (and Guided Exercise)
• Programming with a REST API (and Guided
Exercise)

LAB Centralizing Identity Management

RH362-RHEL-7.4-en-1-20181003 35
CHAPTER 2 | Centralizing Identity Management

MANAGING IDM SERVER CONTENT

OBJECTIVES
After completing this section, students should be able to:

• Manage services running on an Identity Management server

• Create and configure users, groups, and policies

• Describe lifecycle management

INTRODUCTION TO IDENTITY MANAGEMENT

SERVICES
Red Hat Identity Management (IdM) provides a centralized and unified way to manage identity
stores, authentication, policies, and authorization policies in a Linux-based domain. IdM
significantly reduces the administrative overhead of managing different services individually, and
of using different tools on different machines.

IdM is one of the few centralized identity, policy, and authorization software solutions that
supports:

• Advanced features of Linux operating system environments

• Unification of large groups of Linux machines
• Native integration with Active Directory

IdM creates a Linux-based and Linux-controlled domain:

• IdM builds on existing, native Linux tools and protocols. It has its own processes and
configuration, but its underlying technologies are well-established on Linux systems and trusted
by Linux administrators.

• IdM servers and clients are Red Hat Enterprise Linux machines. However, even though it does
not support Windows clients directly, IdM allows integration with Active Directory environment.

A number of different services are installed together with an IdM server, including Directory Server,
Certificate Authority (CA), DNS, Kerberos, and more.

The following figure shows IdM server components. The arrow lines show the sub-components that
store their data directly in the LDAP database, and communicate with a directory server.

36 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Figure 2.1: Identity Management server hosted services

IdM Server Hosted Services

LDAP directory server

IdM includes an internal LDAP directory server instance where it stores all the IdM information,
such as information related to Kerberos, user accounts, host entries, services, policies, DNS,
and so on.

Certiﬁcate System
In most deployments, an integrated certificate authority (CA) is installed with the IdM server.
You can also install the server without the integrated CA if you create and provide all required
certificates independently.

Kerberos KDC
IdM uses the Kerberos protocol to support single sign-on. With Kerberos, the user only needs
to present the correct user name and password once. The user can then access IdM services
without the system prompting for the credentials again.

Domain Name System (DNS)

IdM uses DNS for dynamic service discovery. The IdM client installation utility can use
information from DNS to automatically configure the client machine. After the client is
enrolled in the IdM domain, it uses DNS to locate IdM servers and services within the domain.

Network Time Protocol

Many services require that servers and clients have the same system time, within a certain
variance. For example, Kerberos tickets use time stamps to determine their validity and to
prevent replay attacks. If the times between the server and client skew outside the allowed
range, then the Kerberos tickets are invalidated.

RH362-RHEL-7.4-en-1-20181003 37
CHAPTER 2 | Centralizing Identity Management

By default, IdM uses the Network Time Protocol (NTP) to synchronize clocks over a network.
With NTP, a central server acts as an authoritative clock and the clients synchronize their times
to match the server clock. The IdM server is configured as the NTP server for the IdM domain
during the server installation process.

Management Interface
The management interfaces exposes a JSON-RPC API that the web console and the
command-line interface use for interacting with the IdM server.

MANAGING THE IDM SERVER FROM THE COMMAND

LINE
IdM creates a domain of recognized services, host machines, and users with universally-applied
authentication sources and common policies. From the perspective of a client machine and an IdM
user, the domain itself is fairly transparent after the initial configuration. All users need to do is log
in to the domain using Kerberos.

However, an administrator is tasked with adding principals to the IdM Kerberos domain and
setting the domain policies and server configuration that govern domain interactions. Identity
Management has both command-line and web-based interfaces for administrators to use to
manage the domain, services, and IdM entries. The most common method to maintain a domain is
using command-line tools.

Command-line tools include:

kinit
This utility is used for obtaining and caching Kerberos tickets. A ticket is used to log in to IdM
from the command line.

When it is run without a user name specified, kinit logs in to IdM under the user name of the
user that is currently logged-in on the local system.

klist
This utility is used for listing the cached tickets.

kdestroy
This utility is used for restoring the original ticket stored in the default credential cache.

ipactl
An IPA server control interface utility used to control the IPA environment. Use the ipactl
utility to stop, start, or restart the IdM server along with all associated services.

ipa
An IPA command-line interface (CLI) used to execute administrative commands specified by
the COMMAND argument, such as, user-add, group-add, and others.

The majority of commands are executed remotely over XML-RPC on an IPA server listed in the
/etc/ipa/default.conf configuration file.

MANAGING USERS IN IDM

Using the IPA CLI to Manage Users
The ipa utility and command options are used to manage the user life cycle. Administrators must
first authenticate to IdM using the kinit command. Kerberos will be discussed in detail in the next
chapter.

[user@demo ~]$ kinit

Password for user@EXAMPLE.COM:

38 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

ipa user-add
To create a user named demouser with a first name of demo and a last name of user execute the
following command:

[root@demo ~]$ ipa user-add demouser --first demo --last user

ipa group-add
To create a new group with name demogroup and description "This is a demonstration group"
execute the following command:

[root@demo ~]$ ipa group-add demogroup --desc "This is a demonstration group"

ipa group-add-member
To add the user demouser to the group demogroup execute the following command:

[root@demo ~]$ ipa group-add-member demogroup --users=demouser

IDM WEB CONSOLE

The Identity Management web UI is a web application for IdM administration. It has most of
the capabilities of the ipa command-line utility, so administrators can choose to manage IdM
graphically or from the command-line.

Management operations available to the logged-in user depend on the user's access rights. For the
admin user and other users with administrative privileges, all management tasks are available. For
regular users, only a limited set of operations related to their own user account is available.

The web UI is intuitive, so its features are not described here.

MANAGING PASSWORD POLICIES IN IDM

All users must have a password to authenticate to the Identity Management (IdM) domain.
Password policies in IdM define the requirements that these user passwords must adhere to. A
password policy is a set of rules that apply to passwords. This helps reduce the risk of someone
discovering and misusing a user's password.

A password policy can define many characteristics that a password must have. The following list
describes the options applicable to those characteristics when configuring password policies:

• maxlife: the maximum password lifetime in days

• minlife: the minimum password lifetime in hours

• history: the number of previous passwords that IdM will remember

• minclasses: the minimum number of character classes that a password must contain, such as
uppercase, lowercase, numbers, and special characters like punctuation

• minlength: the minimum length of a password

Setting a password policy attribute to 0 means no attribute restriction. For example, if you set
maximum lifetime to 0, user passwords never expire.

Global and Group-speciﬁc Password Policies

The default password policy is the global password policy. Administrators can create additional
group password policies to override the global password policy.

RH362-RHEL-7.4-en-1-20181003 39
CHAPTER 2 | Centralizing Identity Management

Installing the first IdM server automatically creates a global password policy with default settings.
The global policy rules apply to all users without a group password policy. Group password policies
apply to all members of the corresponding user group.

Password Policy Priorities

Only one password policy can be in effect at a time for a user. If a user has multiple group password
policies assigned, the one with the lowest priority value takes precedence and all rules defined in
other policies are ignored.

The priority of a group password policy is configured using the --priority option. The lowest
supported priority value is 0.

The global password policy does not have a priority value set. It serves as a fallback policy when no
group password policy is set for a user. The global password policy can never take precedence over
a group password policy.

Using the IPA CLI to Manage Password Policies

The ipa utility and command options are used to create and modify password policies. The
following example uses the ipa pwpolicy-add command to create a new group password policy:

[user@demo ~]$ ipa pwpolicy-add demogroup --minlength=10 --minclasses=4 --

priority=10

This next example uses the ipa pwpolicy-mod command to modify the global password policy.
By omitting the group name, the global password policy is affected.

[user@demo ~]$ ipa pwpolicy-mod --maxfail=5

NOTE
When you modify a password policy, the new rules only apply to future password
changes. The rules are not applied retroactively to existing passwords.

USER LIFE CYCLE

Life cycle management starts when a user account is provisioned. A provisioned account begins
the relationship that continues through all changes, such as promotions, or location changes,
and name or status changes. When the relationship ends, if the user leaves the organization for
example, the account should be deprovisioned.

40 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Figure 2.2: User life cycle

MANAGING USER ACCOUNT STATES

Identity Management supports three user account states: stage, active, and preserved.

Stage
This is an initial state in which the user is not permitted to authenticate. This state may be
useful when an account is being provisioned for a user who has not yet started employment
with the organization. Some of the user account properties required for active users might not
be set.

Active
Users are allowed to authenticate. All required user account properties must be set in this
state.

Preserved
Users are formerly active users. They are considered inactive and cannot authenticate to IdM.
Preserved users retain most of the account properties they had as active users, but they are
not part of any user groups.

User entries can also be permanently deleted from the IdM database. Deleting a user entry
permanently removes the entry itself and all its information from IdM, including group
memberships and passwords. Any external configuration for the user, such as the system account
and home directory, is not deleted, but is no longer accessible through IdM.

IMPORTANT
Deleted user accounts cannot be restored. When you delete a user account, all the
information associated with the account is lost permanently.

Administrator Accounts
A new administrator user can only be created by another administrator, such as the default admin
user. If you accidentally delete all administrator accounts, the directory manager must create a new
administrator manually in the directory.

RH362-RHEL-7.4-en-1-20181003 41
CHAPTER 2 | Centralizing Identity Management

User Life Cycle Management Operations

To manage user provisioning, an administrator can move user accounts from one state to another.
New user accounts can be added as either active or stage, but not as preserved.

IdM supports the following operations for user life cycle management:

stage -> active

When an account in the stage state is ready to be properly activated, the administrator moves
it to the active state.

active -> preserved

After the user leaves the company, the administrator moves the account to the preserved
state.

preserved -> active

A former user joins the company again. The administrator restores the user account by moving
it from the preserved state back to the active state.

preserved -> stage

A former user is planning to join the company again. The administrator moves the account
from the preserved state to the stage state to prepare the account for later reactivation.

You can also permanently delete active, stage, and preserved users from IdM.

NOTE
You cannot move stage users to the preserved state, you can only delete them
permanently.

Figure 2.3: Staging users in IdM

MANAGING SERVER CONTENT

The ipactl command starts and stops IdM services, such as ipa-dnskeysyncd or httpd.
Therefore, the services should not be managed manually. External services, such as DNS or NTP,
are not managed by the ipactl command.

1. From the Identity Management (IdM) server, use basic ipactl command options to access the
help section, to start, stop, or restart the IdM server.

2. Use the kinit command to authenticate to the IdM server as the admin user. Use the klist
command to verify the validity of the Kerberos ticket.

42 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

3. Use the ipa command's help option to explore general help and specific help for commands
such as, for example, user-add.

4. Use the ipa command to manage user and group accounts. Use commands to add and stage
users, add groups, modify users and groups, and delete users and groups.

REFERENCES
Further information is available in the chapter on Administration: Managing Servers
in the Red Hat Enterprise Linux 7 Using Red Hat Identity Management in Linux
Environments at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/linux_domain_identity_authentication_and_policy_guide/index

RH362-RHEL-7.4-en-1-20181003 43
CHAPTER 2 | Centralizing Identity Management

GUIDED EXERCISE

MANAGING IDM SERVER CONTENT

In this exercise, you will manage centralized Identity Management content in a newly
installed IdM environment.

OUTCOMES
You should be able to:

• Manage the IdM services.

• Create and manage users and policies.

• Describe life cycle management.

Log in to workstation as student using student as the password. Run the lab manage-
server setup command. The script ensures that the IdM environment is running and that user
utilities are installed in the environment.

[student@workstation ~]$ lab manage-server setup

1. Log in to the IdM server as root user, then run the ipactl command to stop, then start the
IdM services.
1.1. From workstation, open a new terminal and log in to idm.lab.example.net as
the student user then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Use the ipactl command to stop all IdM services.

[root@idm ~]# ipactl stop

Stopping ipa-dnskeysyncd Service
Stopping ipa-otpd Service
Stopping pki-tomcatd Service
Stopping ntpd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping named Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory Service
ipa: INFO: The ipactl command was successful

1.3. Use the ipactl command to start all IdM services.

44 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

[root@idm ~]# ipactl start

Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

2. Ensure that the Identity Management service is ready to deliver Kerberos tickets. Use
kinit admin to authenticate and obtain Kerberos credentials, then use the klist
command to verify that the Kerberos ticket is created. When prompted, use a password of
RedHat123^.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^
[root@idm ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

14/02/18 16:07:29 15/02/18 16:07:27 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

3. Use the ipa command to create staged users and active users. Then, use the ipa command
to display user accounts, activate a staged user, and disable, delete and modify users.
3.1. Review the help options for the ipa stageuser-add verb. Use this same method
to discover help options for the remaining ipa verbs during this exercise.

[root@idm ~]# ipa help stageuser-add

Usage: ipa [global-options] stageuser-add LOGIN [options]

Add a new stage user.

Options:
-h, --help show this help message and exit
--first=STR First name
...output omitted...

3.2. Create the staged user idmuser01. Use user01 as the first name and idm as last
name. Use student@lab.example.net as the email address. Import the user
public key located at /root/RH362/labs/manage-server/student-pub.key.
Use a command redirection and point to the public key.

[root@idm ~]# ipa stageuser-add idmuser01 \

--first=user01 --last=idm \
--email=student@lab.example.net \
--sshpubkey="$(cat /root/RH362/labs/manage-server/student-pub.key)"
--------------------------
Added stage user "student"

RH362-RHEL-7.4-en-1-20181003 45
CHAPTER 2 | Centralizing Identity Management

--------------------------
User login: idmuser01
First name: user01
Last name: idm
Full name: user01 idm
Display name: user01 idm
Initials: SS
Home directory: /home/idmuser01
GECOS: user01 idm
Login shell: /bin/sh
Principal name: idmuser01@LAB.EXAMPLE.NET
Principal alias: idmuser01@LAB.EXAMPLE.NET
Email address: student@lab.example.net
UID: -1
GID: -1
SSH public key: ssh-rsa
AAAAB3...LUsoaHLT
student@workstation.lab.example.net
SSH public key fingerprint: SHA256:Svxq2+...SkJGy8
student@workstation.lab.example.net (ssh-rsa)
Password: False
Kerberos keys available: False

3.3. Create the active user idmuser02. Use user02 as the first name, idm as last name,
and idmuser02@lab.example.net as the email address. Use the password
option to be prompted for the user password, redhat.

[root@idm ~]# ipa user-add idmuser02 \

--first=user02 --last=idm \
--email=idmuser02@lab.example.net \
--password
Password: redhat
Enter Password again to verify: redhat
Added user "idmuser02"
-----------------------
User login: idmuser02
First name: user02
Last name: idm
Full name: user02 idm
Display name: user02 idm
Initials: SS
Home directory: /home/idmuser02
GECOS: user02 idm
Login shell: /bin/sh
Principal name: idmuser02@LAB.EXAMPLE.NET
Principal alias: idmuser02@LAB.EXAMPLE.NET
Email address: idmuser02@lab.example.net
UID: 1411000001
GID: 1411000001
Password: True
Member of groups: ipausers

46 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Kerberos keys available: False

3.4. Create the active user idmuser03. Use user03 as the first name, idm as last name,
and idmuser03@lab.example.net as the email address. Use a password of
RedHat123^.

[root@idm ~]# ipa user-add idmuser03 \

--first=user03 --last=idm \
--email=idmuser03@lab.example.net \
--password
Password: RedHat123^
Enter Password again to verify: RedHat123^
-----------------------
Added user "idmuser03"
-----------------------
User login: idmuser03
First name: user03
Last name: idm
Full name: user03 idm
Display name: user03 idm
Initials: SS
Home directory: /home/idmuser03
GECOS: user03 idm
Login shell: /bin/sh
Principal name: idmuser03@LAB.EXAMPLE.NET
Principal alias: idmuser03@LAB.EXAMPLE.NET
Email address: idmuser03@lab.example.net
UID: 1411000003
GID: 1411000003
Password: True
Member of groups: ipausers
Kerberos keys available: False

3.5. Create the staged user idmuser04. Use user04 as the first name, idm as last name,
and idmuser04@lab.example.net as the email address.

[root@idm ~]# ipa stageuser-add idmuser04 \

--first=user04 --last=idm \
--email=idmuser04@lab.example.net
--------------------------
Added stage user "idmuser04"
--------------------------
User login: idmuser04
First name: user04
Last name: idm
Full name: user04 idm
Display name: user04 idm
Initials: OS
Home directory: /home/idmuser04
GECOS: user04 idm
Login shell: /bin/sh
Principal name: idmuser04@LAB.EXAMPLE.NET
Principal alias: idmuser04@LAB.EXAMPLE.NET
Email address: idmuser04@lab.example.net
UID: -1
GID: -1

RH362-RHEL-7.4-en-1-20181003 47
CHAPTER 2 | Centralizing Identity Management

Password: False
Kerberos keys available: False

3.6. Retrieve the list of active and staged users. Three active users should be listed and
two staged users.

[root@idm ~]# ipa user-find

---------------
3 users matched
---------------
User login: admin
Last name: Administrator
Home directory: /home/admin
Login shell: /bin/bash
Principal alias: admin@LAB.EXAMPLE.NET
UID: 1411000000
GID: 1411000000
Account disabled: False

User login: idmuser02

First name: user02
Last name: idm
Home directory: /home/idmuser02
Login shell: /bin/sh
Principal name: idmuser02@LAB.EXAMPLE.NET
Principal alias: idmuser02@LAB.EXAMPLE.NET
Email address: idmuser02@lab.example.net
UID: 1411000001
GID: 1411000001
Account disabled: False
----------------------------
Number of entries returned 3
----------------------------

[root@idm ~]# ipa stageuser-find

---------------
2 users matched
---------------
User login: idmuser04
First name: user04
Last name: idm
Home directory: /home/idmuser04
Login shell: /bin/sh
Principal name: idmuser04@LAB.EXAMPLE.NET
Principal alias: idmuser04@LAB.EXAMPLE.NET
Email address: idmuser04@lab.example.net
UID: -1
GID: -1

User login: idmuser01

First name: user01
Last name: idm
Home directory: /home/idmuser01
Login shell: /bin/sh
Principal name: idmuser01@LAB.EXAMPLE.NET
Principal alias: idmuser01@LAB.EXAMPLE.NET

48 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Email address: student@lab.example.net

UID: -1
GID: -1
SSH public key fingerprint: SHA256:Svxq2+...student@workstation.lab.example.net
(ssh-rsa)
----------------------------
Number of entries returned 2
----------------------------

3.7. Move the idmuser01 user from staged to active.

[root@idm ~]# ipa stageuser-activate idmuser01

------------------------------
Stage user idmuser01 activated
------------------------------
...output omitted...

3.8. Disable the idmuser02 account. Deactivation prevents the user from logging in, but
preserves the user information.

[root@idm ~]# ipa user-disable idmuser02

---------------------------------
Disabled user account "idmuser02"
---------------------------------

3.9. Delete the staged user idmuser04. The --preserve option is not available for
staged users.

[root@idm ~]# ipa stageuser-del idmuser04

------------------------------
Deleted stage user "idmuser04"
------------------------------

3.10. Use the user-mod verb to update the email address of the idmuser01 account. Use
an email address of idmuser01@lab.example.net.

[root@idm ~]# ipa user-mod idmuser01 \

--email=idmuser01@lab.example.net
-------------------------
Modified user "idmuser01"
-------------------------
User login: idmuser01
First name: user01
Last name: idm
Home directory: /home/idmuser01
Login shell: /bin/sh
Principal name: idmuser01@LAB.EXAMPLE.NET
Principal alias: idmuser01@LAB.EXAMPLE.NET
Email address: idmuser01@lab.example.net
...output omitted...

RH362-RHEL-7.4-en-1-20181003 49
CHAPTER 2 | Centralizing Identity Management

4. Use the ipa command to create groups. Then, use the ipa command to modify groups, add
users to groups, and delete groups.
4.1. Review the usage of the group-add verb and inspect the available options.

[root@idm ~]# ipa help group-add

Usage: ipa [global-options] group-add GROUP-NAME [options]

Create a new group.

...output omitted...

4.2. Use the ipa group-add command to create the idmgroup01 group.

[root@idm ~]# ipa group-add idmgroup01

------------------------
Added group "idmgroup01"
------------------------
Group name: idmgroup01
GID: 1411000005

4.3. Repeat the previous step for the idmgroup02 and idmgroup03 groups.

[root@idm ~]# ipa group-add idmgroup02

------------------------
Added group "idmgroup02"
------------------------
Group name: idmgroup02
GID: 1411000006
[root@idm ~]# ipa group-add idmgroup03
------------------------
Added group "idmgroup03"
------------------------
Group name: idmgroup03
GID: 1411000007

4.4. Modify the description for the idmgroup03 group by giving a description of Devops
Groups.

[root@idm ~]# ipa group-mod idmgroup03 --desc "Devops Group"

---------------------------
Modified group "idmgroup03"
---------------------------
Group name: idmgroup03
Description: Devops Group
GID: 1411000007

4.5. Add users to the previously created groups. Review the usage of the group-add-
member verb and inspect the available options.

[root@idm ~]# ipa help group-add-member

Usage: ipa [global-options] group-add-member GROUP-NAME [options]

Add members to a group.

Options:

50 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

...output omitted...

4.6. Add the idmuser01 and idmuser03 users to the idmgroup03 group using the --
users option.

[root@idm ~]# ipa group-add-member idmgroup03 --users={idmuser01,idmuser03}

Group name: idmgroup03
Description: Devops Group
GID: 1411000007
Member users: idmuser01, idmuser03
-------------------------
Number of members added 2
-------------------------

4.7. Delete the idmgroup01 group.

[root@idm ~]# ipa group-del idmgroup01

--------------------------
Deleted group "idmgroup01"
--------------------------

5. Use the ipa command to modify an existing policy and add the policy to a group.
5.1. Review the management of policies by inspecting the pwpolicy-mod verb. The
option allows you to manage global password policies.

[root@idm ~]# ipa help pwpolicy-mod

Usage: ipa [global-options] pwpolicy-mod [GROUP] [options]

Modify a group password policy.

Options:
...output omitted...

5.2. Update the global password policy with the following rules:

• A minimum password length of ten characters

• A lockout after five failed attempts

• A lockout duration of twenty minutes

[root@idm ~]# ipa pwpolicy-mod \

--minlength=10 \
--maxfail=5 \
--lockouttime=1200
Group: global_policy
Max lifetime (days): 90
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 10
Max failures: 5
Failure reset interval: 60

RH362-RHEL-7.4-en-1-20181003 51
CHAPTER 2 | Centralizing Identity Management

Lockout duration: 1200

5.3. Add a group-specific password policy for the idmgroup03 group. Set a password
policy that defines the minimum password length to eight characters. Give the policy
a priority of one, which forces the default policy to take precedence over this group
policy.

[root@idm ~]# ipa pwpolicy-add idmgroup03 \

--minlength 8 \
--priority 1
Group: idmgroup03
Min length: 8
Priority: 1

6. Use SSH to log in to various servers to test user accounts. Use the passwd command to test
the new password policy.
6.1. From workstation, open a new terminal and use the ssh command to log in to the
idm server as the idmuser03 user. You should automatically be logged in. Notice
the default sh logging shell.

[student@workstation ~]$ ssh idmuser03@idm.lab.example.net

Creating home directory for idmuser03.
-sh-4.2$

6.2. Test the password policy by changing the user password. Use a password of r3d4t
The password will be rejected, as it is too short for the policy defined for the users.

-sh-4.2$ passwd
Changing password for user idmuser03.
Current Password: RedHat123^
New password: r3d4t
Retype new password: r3d4t
Password change failed. Server message: Password is too short

Password not changed.

passwd: Authentication token manipulation error.

6.3. Repeat the previous step with a password of RedHat123^@1. The password will be
accepted.

-sh-4.2$ passwd
Changing password for user idmuser03.
Current Password: RedHat123^
New password: RedHat123^@1
Retype new password: RedHat123^@1
passwd: all authentication tokens updated successfully.

6.4. Log out and log back in as the idmuser02 user. The ssh authentication should fail.

[student@workstation ~]$ ssh idmuser02@idm

52 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Authentication failed.

6.5. Log in to the idm server as the student user, become root then restore the
idmuser02 user.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# ipa user-enable idmuser02
--------------------------------
Enabled user account "idmuser02"
--------------------------------

6.6. Add the idmuser02 user to the idmgroup03 group.

[root@idm ~]# ipa group-add-member idmgroup03 --users=idmuser02

Group name: idmgroup03
Description: Devops Group
GID: 1411000007
Member users: idmuser01, idmuser02, idmuser03
-------------------------
Number of members added 1
-------------------------

6.7. From workstation, open a new terminal and log in to the idm server as the
idmuser02 user. When logged in, use the openssl command to generate a
password that conforms to the minimum length defined by the policy. Copy the
password in the clipboard.

[student@workstation ~]$ ssh idmuser02@idm

Creating home directory for idmuser02.
There were 1 failed login attempts since the last successful login.
-sh-4.2$ openssl rand -base64 10
I2cCwIqq1QB2MA==
-sh-4.2$ passwd
Current Password: redhat
New password: I2cCwIqq1QB2MA==
Retype new password: I2cCwIqq1QB2MA==
passwd: all authentication tokens updated successfully.

6.8. Exit from the idm server.

-sh-4.2$ exit
[student@workstation ~]$

From the workstation VM, run the lab manage-server cleanup command to clean the
resources created in the exercise.

[student@workstation ~]$ lab manage-server cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 53
CHAPTER 2 | Centralizing Identity Management

MANAGING IDM CLIENTS

OBJECTIVES
After completing this section, students should be able to:

• Install and connect clients.

• Describe automated provisioning choices.

INSTALLING IDENTITY MANAGEMENT CLIENTS

Upon the deployment of an Identity Management (IdM) server, administrators are able to enroll
clients. An IdM client is a system that can authenticate users who are members of the IdM domain.
It is common to use Red Hat Linux systems as clients, as the IdM server provides a set of dedicated
tools for configuring Red Hat clients. However, it is also possible to enroll other operating systems
to an IdM domain.

NOTE
IdM does not require any agent or daemon to be running on a client. However, to
improve management options, security, and performance, clients should run the
System Security Services Daemon (SSSD).

SSSD is discussed later in this section.

Prerequisites for Installing a Client

Before enrolling a client, a system must meet the following requirements:

• Install the ipa-client package on the client.

• The system must be able to reach the Kerberos domain. This can be accomplished by either
having an available Kerberos identity, such as the administrative user, or by manually adding the
client machine to the Key Distribution Center (KDC) on the IdM server.

• If there is an Active Directory server on the same network that serves DNS records, the Active
Directory DNS records could prevent the client from automatically detecting the IdM server
address. The ipa-client-install command could retrieve the Active Directory DNS records
instead of any records that are added for IdM. If this is the case, you must pass the IdM server
address directly to the ipa-client-install command.

• Red Hat recommends disabling NSCD (Name Service Caching Daemon) on the clients. If disabling
NSCD is not possible, Red Hat recommends only enabling NSCD for maps that SSSD does not
cache. The NSCD and the SSSD services perform caching, which can lead to problems when the
services are used together.

Requirements for Installing Clients

To enroll a client on a Linux system, install the ipa-client package. The package automatically
installs all other required packages as dependencies, which includes the SSSD package and SASL
libraries.

54 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

The ipa-client-install command installs and configures the host as an IdM client. During the
installation process, you are required to provide credentials that are used to enroll the client. Three
authentication methods are supported:

1. Explicit usage of credentials of an authorized user, such as the administrative user. The ipa-
client-install command uses credentials as the default method.

2. A random One-Time Password (OTP), generated by the server. To use an OTP, pass the --
random option when running the ipa-client-install command.

3. A principal from a previous enrollment. To use the principal method, add the --keytab option
when running the ipa-client-install command.

INSTALLATION METHODS
There are two ways to enroll a client:

• The manual, interactive method. The interactive method prompts you for various settings, such
as the Kerberos principal, the domain, and an administrative password. The interactive method is
useful for troubleshooting or getting acquainted with the product.

• An automated, non-interactive method. Such a method provides all required information to the
ipa-client-install command by parsing a set of parameters passed as options.

There are minimum requirements in order to use the non-interactive method: the options that
specify the credentials, and the use of the --unattended option that bypasses any user
confirmation for the installation of the client.

Enrolling Clients Using the Manual Installation

When using the manual or interactive installation, you are prompted for the various settings
that define the IdM domain. This includes the host name, and the name and password of the
administrative user. The following procedure describes the steps to install a client using the
interactive method.

1. Run the ipa-client-install command. If the IdM server is installed with integrated DNS,
or if the DNS server on the network accepts DNS entry updates (from Generic Security Service
Algorithm for Secret Key Transaction, GSS-TSIG protocol), then use the --enable-dns-
updates option.

To disable storage of Kerberos passwords when using SSSD, use the --no-krb5-offline-
passwords option.

2. The installer attempts to obtain all the required settings automatically. If your DNS zone and
SRV records are correctly configured, the script is able to discover all the required values and
output them:

Client hostname: demo.lab.example.com

Realm: LAB.EXAMPLE.COM
DNS Domain: lab.example.com
IPA Server: idm.lab.example.com
BaseDN: dc=lab,dc=example,dc=com
Continue to configure the system with these values? [no]: yes

To input different values, cancel the current installation, then rerun the command and provide
the required values using the command-line options.

RH362-RHEL-7.4-en-1-20181003 55
CHAPTER 2 | Centralizing Identity Management

NOTE
If the installer is not able to obtain certain settings automatically, then it prompts
you for the values.

IMPORTANT
The fully qualified domain name must be a valid DNS name, which means only
numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, such
as underscores, in the host name may cause DNS failures.

Additionally, the host name must be all lowercase. For recommended naming
practices, consult the Recommended Naming Practices section of the Red Hat
Enterprise Linux Security Guide, listed in the References at the end of this section.

3. The installer prompts for a user identity to enroll the client. By default, the installer uses the
admin user:

User authorized to enroll computers: admin

Password for admin@LAB.EXAMPLE.COM

4. The installer is now able to configure the client. This includes enrollment in the realm, the
SSSD configuration, and the creation of SSH public keys:

...output omitted...
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring lab.example.net as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

5. Optionally, run the ipa-client-automount command, which automatically configures NFS

for IdM.

Enrolling Clients Using the Unattended Installation

You can install the IdM server in an unattended mode, that is, an automated installation that
parses the various options passed on the command line. For an unattended installation, provide all
required information to the ipa-client-install utility using command-line options. Use the
--unattended option to let the installation run without requiring confirmation.

The following table lists the options supported by the automated installer. Each option requires a
double dash to be treated as an option, for example, --unattended.

OPTION DESCRIPTION

--unattended Indicates to the installation to run without requiring

user confirmation.

--hostname Specifies the host name for the client machine.

56 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

OPTION DESCRIPTION

--password Specifies the password to use for the enrollment. See

below for usage of this option.

--server Specifies the host name of the IdM server that the client
uses for the enrollment.

--domain Specifies the host name of the IdM server that the client
uses for the enrollment.

--realm Specifies the Kerberos realm name.

--enable-dns-updates Updates the DNS records with the client machine's IP

address.

This only applies if the IdM server is installed with

integrated DNS or if GSS-TSIG is configured on the DNS
servers present in the network.

--no-krb5-offline- Disables storage of the Kerberos passwords in the SSSD

passwords cache.

You can generate a random one-time password for any new client you need to enroll. To generate a
one-time password:

1. Run the kinit command to obtain a Kerberos ticket from any enrolled client.

[user@demo ~]$ kinit admin

2. Use the --random option with the ipa host-add command to generate the random
password. The password is used for the enrollment process.

[user@demo ~]$ ipa host-add client.example.com --random

--------------------------------------------------
Added host "client.example.com"
--------------------------------------------------
Host name: client.example.com
Random password: W5YpARl=7M.n
Password: True
Keytab: False
Managed by: server.example.com

NOTE
After you use the password to enroll the machine in the IdM domain, it becomes
invalid. It is replaced with a proper host keytab upon enrollment.

Unattended installation is useful in scripts and for automation solutions, such as Red Hat
Ansible Automation. For example, you can create an Ansible Playbook that configures the IdM
environment.

The following excerpt displays an Ansible Playbook that contains tasks for installing an IdM client
in unattended mode:

RH362-RHEL-7.4-en-1-20181003 57
CHAPTER 2 | Centralizing Identity Management

- hosts: "{{ ipa_client }}"

vars:

ipa_server: idm.lab.example.com
ipa_server_ip: 172.25.250.8
ipa_domain: lab.example.net
ipa_realm: LAB.EXAMPLE.NET
ipa_admin_password: RedHat123^

tasks:

- name: Get Kerberos credentials as IPA admin

shell: echo "{{ipa_admin_password }}" | kinit -f admin
ignore_errors: yes
register: cred_result
changed_when: false

- name: IPA client packages installed

package:
name: ipa-client
state: latest

- name: Install IPA client

command: >
ipa-client-install
--principal=admin
--password={{ ipa_admin_password }}
--unattended
when: "'kinit: Configuration file does not specify default realm when
parsing name admin' in cred_result.stderr"

Defines the variables used by the unattended installation, such as the domain and the IP
address of the IdM server.
Defines the host name of the IPA server.
Authenticates against the IdM server prior to installation.
Installs the required packages.
Defines the command to run for the unattended installation. The task runs the installation
command by passing the content of the Ansible variables as the options.

ENROLLING IDM CLIENTS USING KICKSTART

You can use Kickstart to automatically enroll clients to an IdM domain. The Kickstart method
enrolls the client during the installation of the Red Hat Enterprise Linux operating system.

To automatically enroll a client by using Kickstart:

1. Run the kinit command to obtain a Kerberos ticket from any enrolled client.

[user@demo ~]$ kinit admin

2. Use the --random option with the ipa host-add command to generate a random
password. This password is used for the enrollment process.

[user@demo ~]$ ipa host-add client.example.com --random

--------------------------------------------------

58 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Added host "client.example.com"

--------------------------------------------------
Host name: client.example.com
Random password: W5YpARl=7M.n
Password: True
Keytab: False
Managed by: server.example.com

3. Add the ipa-client package in the %packages group.

%packages
@ X Window System
@ Desktop
@ Sound and Video
ipa-client
...output omitted...

4. Add the installation directive in the %post section of the Kickstart file.

%post --log=/root/ks-post.log
## SSH Keys

/usr/sbin/sshd-keygen

## Environment Variables
env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list

env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install

## IPA Client Installation

/usr/sbin/ipa-client-install \
--hostname=client.example.com \
--domain=EXAMPLE.COM \
--enable-dns-updates \
--mkhomedir \
--password W5YpARl=7M.n \
--realm=EXAMPLE.COM \
--server=server.example.com \
--unattended

Generates SSH keys to ensure that the ipa-client-install command uploads them to
the IdM server.
Sets the system bus address to /dev/null for the getcert and ipa-client-install
utilities.
Runs the enrollment process in unattended mode.

IMPORTANT
Red Hat recommends not to start the sshd service prior to Kickstart enrollment.

Post-Installation Steps
The ipa-client-install utility does not remove any previous LDAP and SSSD configuration
from the /etc/openldap/ldap.conf and /etc/sssd/sssd.conf files. If you changed the
configuration in the files before enrolling the client, the script adds the new client values, but
comments them out.

RH362-RHEL-7.4-en-1-20181003 59
CHAPTER 2 | Centralizing Identity Management

The following excerpt shows the modified ldap.conf configuration file.

BASE dc=example,dc=com

URI ldap://ldap.example.com
# URI ldaps://server.example.com # modified by IPA
# BASE dc=ipa,dc=example,dc=com # modified by IPA

To apply the new IdM configuration values:

1. Open the /etc/openldap/ldap.conf and /etc/sssd/sssd.conf configuration files

and delete the previous configuration.

2. Uncomment the new IdM configuration.

3. Restart the services that rely on the LDAP configuration to apply the changes. Applications
that use the openldap libraries import the configuration when started.

Testing the Client

Upon enrollment of the client, ensure that the client can obtain information about the users
defined in the server. To do so, run the id command. The output indicates that the admin user is
resolved on the client machine.

[user@client ~]$ id admin

uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

UNINSTALLING CLIENTS
You can uninstall a client at any time. Uninstalling a client removes the client from the IdM domain,
along with all of the IdM-specific configuration for the system services, such as the SSSD daemon.
This restores the client machine's previous configuration.

To uninstall a client, run the ipa-client-install with the --uninstall option, then remove
the DNS entries from the client.

Enrolling a Previously Uninstalled Client

If a client is unenrolled, but still has its Keytab, you can enroll it back either interactively or non-
interactively. Re-enrollment using the client Keytab is appropriate for automated installation, or in
other situations when using the administrator password is not possible.

• To enroll a client interactively, give the client the same host name, and run the ipa-client-
install with the --force-join option.

[user@client ~]$ ipa-client-install --force-join

• To enroll a client non-interactively, back up the original client's Keytab file.

Recreate the client machine with the same host name, place the back-up Keytab in the /tmp or /
root directory, then run the ipa-client-install with the --keytab option.

[user@client ~]$ ipa-client-install --keytab /tmp/krb5.keytab

60 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

NOTE
The Keytab specified by the --keytab option is only used when authenticating the
client during the initial enrollment. During the re-enrollment process, the IdM server
generates a new Keytab for the client.

IDM CLIENT COMPONENTS

IdM clients do not require dedicated client software to interact as a part of a domain. Clients only
require proper system configuration of certain services and libraries, such as Kerberos or DNS.

The list of services hosted by IdM clients includes:

• The System Security Services Daemon (SSSD), a client-side application for caching credentials.
This service is recommended, as it simplifies client configuration. This service also provides
offline client authentication, consistency of the authentication process, integration with other
services such as sudo, and Host-Based Access Control (HBAC) authorization.

• certmonger. The certmonger service monitors and renews the security certificates on the
client. This service can request new certificates for the services on the system.

NOTE
For more information about the certmonger service, consult the System-Level
Authentication Guide for Red Hat Enterprise Linux listed in the references section.

Figure 2.4: Hosted services on IdM clients.

EXPLORING THE IDM WEB CONSOLE

The IdM web console is a web application for the administration of an IdM server. The web console
has most of the capabilities of the ipa command-line utility. Therefore, you can choose whether
you want to manage the IdM server from the web console or by using the command-line interface.
You can manage user life cycle, create policies, or enroll clients with the web console. You can also
use it to reset a user password or change the shell for a user.

RH362-RHEL-7.4-en-1-20181003 61
CHAPTER 2 | Centralizing Identity Management

NOTE
The management operations available to the authenticated user depend on the
user's privileges. For administrative users, all management tasks are available.
However, for regular users, only a limited set of operations, related to their own user
account, is available.

NOTE
In the current version, the web console supports Mozilla Firefox 38 and later, and
Google Chrome 46 and later.

Accessing the Web Console

The web console is accessible from the IdM server and client machines, as well as from machines
outside of the IdM domain. To enable Kerberos authentication to the web console from a server
that is not a member of the IdM domain, you must define an IdM-specific Kerberos configuration
file on the external machine. Enabling Kerberos authentication on external systems is useful when
your infrastructure includes multiple realms or overlapping domains.

The web console is available at https://server.example.com, with server.example.com being

the host name of the IdM server. The web console provides the following authentication methods:

• Authentication with a valid Kerberos ticket, which is obtained with the kinit utility. The console
automatically logs in the client. Note that the web browser must be configured to support
Kerberos authentication.

• Authentication with a user name and password. The web console also supports one-time
passwords for authentication.

• Authentication with a smart card. To use a smart card for authentication, you must link the
certificate from the user's smart card with the matching user account in the IdM server.

After a user authenticates, the IdM management window opens. The following screenshot shows
the management of active, stage, and preserve users from the web console.

Figure 2.5: The IdM web console

The following screenshot shows the various options for managing services from the web console.

62 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Figure 2.6: Managing services with the web console

The following screenshot shows the various options for managing user accounts from the web
console.

Figure 2.7: Managing users with the web console

EXPLORING CLIENT LOG FILES

There are several log files that you can access for an IdM server or for a client. The following table
lists the various log files and their usage.

DIRECTORY OR FILE DESCRIPTION

/var/log/ipaserver- The installation log for the IdM server.

install.log

/var/log/ipareplica- The installation log for an IdM replica.

install.log

/var/log/ipaclient- The installation log for the IdM client.

install.log

RH362-RHEL-7.4-en-1-20181003 63
CHAPTER 2 | Centralizing Identity Management

DIRECTORY OR FILE DESCRIPTION

/var/log/sssd/ SSSD log files.

~/.ipa/log/cli.log The log file for errors returned by XML-RPC calls and
responses by the ipa utility.

The file is created in the home directory for the system user
who runs the ipa tools.

/etc/logrotate.d/ The log rotation policies for DNS, SSSD, Apache, Tomcat,
and Kerberos.

/var/log/httpd/ Log files for the Apache web server.

/var/log/httpd/ Standard access and error logs for Apache servers.

access_log Messages specific to IdM are recorded along with the
Apache messages, as the IdM web interface and the XML-
/var/log/httpd/ RPC command-line interface use Apache.
error_log

/var/log/messages Contains DNS error messages and other system messages.

DNS logging to this file is not enabled by default.

To enable it, run the rndc querylog command. To disable

logging, rerun the command.

To review log entries related to the enrollment of clients, access the IdM server over SSH. Entries
are logged in the /var/log/krb5kdc.log.

[demo@idm ~]# grep client /var/log/krb5kdc.log

...output omitted...
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5777](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 172.25.250.10: NEEDED_PREAUTH: host/
client.lab.example.net@LAB.EXAMPLE.NET for krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET,
Additional pre-authentication required
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5777](info): AS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 172.25.250.10: ISSUE: authtime 1518570570, etypes
{rep=18 tkt=18 ses=18}, host/client.lab.example.net@LAB.EXAMPLE.NET for krbtgt/
LAB.EXAMPLE.NET@LAB.EXAMPLE.NET
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5776](info): TGS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 172.25.250.10: ISSUE: authtime 1518570570, etypes
{rep=18 tkt=18 ses=18}, host/client.lab.example.net@LAB.EXAMPLE.NET for ldap/
idm.lab.example.net@LAB.EXAMPLE.NET

Note the Authentication Server requests (AS_REQ) and the Ticket Granting Server requests
(TGS_REQ).

The /var/log/messages log file also contains entries related to IdM.

[demo@idm ~]# grep client /var/log/messages

...output omitted...
Feb 14 10:39:29 idm named-pkcs11[5944]: client 172.25.250.10#41844/key host/
client.lab.example.net\@LAB.EXAMPLE.NET: updating zone 'lab.example.net/IN':
adding an RR at 'client.lab.example.net' SSHFP

64 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

This log entry shows the creation of an SSH fingerprint (SSHFP) DNS resource record for a client.

MANAGING IDM CLIENTS CONTENT

1. Verify the prerequisites for installing a client, which includes DNS configuration, ports
requirements, FIPS support, and NSCD.

2. Use the yum command to install the ipa-client package.

3. Run the ipa-client-install command with the --unattended option to install the
client non-interactively.

4. Run the id admin command to ensure that the admin user is present on the client system.

5. Log in to the IdM server and review the /var/log/krb5kdc.log and /var/log/
messages logs to ensure that the enrollment succeeded. Locate the authentication server
requests (AS_REQ) and the ticket granting server requests (TGS_REQ).

REFERENCES
ipa-client-install(1) man page.

DNS Autodiscovery section in the ipa-client-install(1) man page.

Further information is available in the Configuring NFS Automatically section of the

Red Hat Enterprise Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/linux_domain_identity_authentication_and_policy_guide/index

Further information is available in the Recommended Naming Practices section of the

Red Hat Enterprise Linux Security Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/security_guide/sec-securing_dns_traffic_with_dnssec#sec-
Recommended_Naming_Practices

Further information is available in the System-Level Authentication Guide for Red Hat
Enterprise Linux at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/system-level_authentication_guide/index

RH362-RHEL-7.4-en-1-20181003 65
CHAPTER 2 | Centralizing Identity Management

GUIDED EXERCISE

MANAGING IDM CLIENTS

In this exercise, you will:

• Install and configure IdM client packages.

• View the web-based interface.

• View client log activity.

OUTCOMES
You should be able to install an IdM client manually, navigate the web interface, and view
client activity.

Log in to workstation as the student user, then open a terminal and execute the lab
manage-clients setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab manage-clients setup

1. Log in to client over SSH as the student user, become root then install the ipa-
client package.
1.1. Log in to the client VM over SSH.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

1.2. Install the ipa-client package.

[root@client ~]# yum install ipa-client

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Installed:
ipa-client.x86_64 0:4.5.0-20.el7

Complete!

2. Change the client's DNS nameserver configuration to use the idm server. Use the nmcli
connection modify command to set the eth0 ipv4.dns option to 172.25.250.8. Use
the nmcli connection up command to activate the DNS change.

[root@client ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

[root@client ~]# nmcli connection up "System eth0"

66 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

3. Use the dig command to perform DNS lookups using SRV records. The ipa-client-
install command performs the same lookups in order to determine the realm, the domain
name, and the IdM server address.

[root@client ~]# dig SRV _ldap._tcp.lab.example.net

... output omitted ...
;_ldap._tcp.lab.example.net. IN SRV

;; ANSWER SECTION:
_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 idm.lab.example.net.

;; AUTHORITY SECTION:
lab.example.net. 86400 IN NS idm.lab.example.net.

;; ADDITIONAL SECTION:
idm.lab.example.net. 1200 IN A 172.25.250.8
... output omitted ...

[root@idm ~]# dig SRV _kerberos._tcp.lab.example.net

... output omitted ...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_kerberos._tcp.lab.example.net. IN SRV

;; ANSWER SECTION:
_kerberos._tcp.lab.example.net. 86400 IN SRV 0 100 88 idm.lab.example.net.

;; AUTHORITY SECTION:
lab.example.net. 86400 IN NS idm.lab.example.net.

;; ADDITIONAL SECTION:
idm.lab.example.net. 1200 IN A 172.25.250.8
... output omitted ...

4. Execute the ipa-client-install command, specifying the --principal, --

password, and --unattended options.

[root@client ~]# ipa-client-install \

--principal=admin \
--password=RedHat123^ \
--unattended
WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

Discovery was successful!

Client hostname: client.lab.example.net
Realm: LAB.EXAMPLE.NET
DNS Domain: lab.example.net
IPA Server: idm.lab.example.net
BaseDN: dc=lab,dc=example,dc=net

Skipping synchronizing time with NTP server.

Successfully retrieved CA cert

RH362-RHEL-7.4-en-1-20181003 67
CHAPTER 2 | Centralizing Identity Management

Subject: CN=Certificate Authority,O=LAB.EXAMPLE.NET

Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Valid From: 2018-02-13 00:54:53
Valid Until: 2038-02-13 00:54:53

Enrolled in IPA realm LAB.EXAMPLE.NET

Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm LAB.EXAMPLE.NET
trying https://idm.lab.example.net/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://idm.lab.example.net/ipa/json'
trying https://idm.lab.example.net/ipa/session/json
[try 1]: Forwarding 'ping' to json server 'https://idm.lab.example.net/ipa/
session/json'
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://idm.lab.example.net/
ipa/session/json'
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
[try 1]: Forwarding 'host_mod' to json server 'https://idm.lab.example.net/ipa/
session/json'
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring lab.example.net as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

5. Verify that you can authenticate to IdM as the admin user. The admin user is created during
IdM server installation to allow initial administrative access to IdM.
5.1. Use the kinit command to authenticate to IdM.

[root@client ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET:RedHat123^

5.2. Use the klist command to view the Kerberos ticket details.

[root@client ~]# klist

Ticket cache: KEYRING:persistent:0:0
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

13/02/18 13:45:56 14/02/18 13:45:53 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET
[root@client ~]# logout
[student@client ~]$ logout
[student@workstation ~]$

Kerberos will be examined in detail in later chapters. At this time, it is enough to

know that if you have a valid ticket, then you have successfully authenticated to IdM.

68 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

6. Log in to the idm server over SSH, then view the log file entries related to client.
6.1. View client log entries for the Kerberos KDC.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# grep client /var/log/krb5kdc.log
...output omitted...
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5777](info): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 172.25.250.10: NEEDED_PREAUTH: host/
client.lab.example.net@LAB.EXAMPLE.NET for krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET,
Additional pre-authentication required
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5777](info): AS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 172.25.250.10: ISSUE: authtime 1518570570, etypes
{rep=18 tkt=18 ses=18}, host/client.lab.example.net@LAB.EXAMPLE.NET for krbtgt/
LAB.EXAMPLE.NET@LAB.EXAMPLE.NET
Feb 14 12:09:30 idm.lab.example.net krb5kdc[5776](info): TGS_REQ (8 etypes
{18 17 20 19 16 23 25 26}) 172.25.250.10: ISSUE: authtime 1518570570, etypes
{rep=18 tkt=18 ses=18}, host/client.lab.example.net@LAB.EXAMPLE.NET for ldap/
idm.lab.example.net@LAB.EXAMPLE.NET

Note the Authentication Server requests (AS_REQ) and the Ticket Granting Server
requests (TGS_REQ).
6.2. View client log entries for the named-pkcs11.service unit.

[root@idm ~]# journalctl -u named-pkcs11.service | grep client.*updating

This log entry shows the creation of an SSH fingerprint (SSHFP) DNS resource record
for the client VM.

7. In a web browser, open the IdM web interface accessible at https://

idm.lab.example.net. Log in as the admin user, with the password RedHat123^. The
default location is the Identity → Users tab.
Note the Active users, Stage users, and Preserved users user categories to the left.
Navigate to the Identity → Hosts tab, then click on client.lab.example.net.
Note that under the Enrollment section, a Kerberos key is present, and the host state is
provisioned.

8. Unenroll client from the IdM domain, then have it rejoin the domain. Observe the changes
to the host record during these operations.
8.1. Log in to client over SSH as student, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student

RH362-RHEL-7.4-en-1-20181003 69
CHAPTER 2 | Centralizing Identity Management

[root@client ~]#

8.2. Authenticate to IdM as the admin user.

[root@client ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET:RedHat123^

8.3. Use the ipa host-show command to view the host record for client.

[root@client ~]# ipa host-show client.lab.example.net

Host name: client.lab.example.net
Principal name: host/client.lab.example.net@LAB.EXAMPLE.NET
Principal alias: host/client.lab.example.net@LAB.EXAMPLE.NET
SSH public key fingerprint: SHA256:SKPbFqfD9FC9OOBraDzDLrXjAqfmRPYl99C7Cn3zak0
(ssh-rsa),
SHA256:lXmpBW0vCfgwrSGzb0qS9KzIlg2fTmp8k/lIsuCW21Q
(ecdsa-sha2-nistp256),
SHA256:lfaB68WElm4Pg78ryMo6yNL3cYxZmpE4dH10s2LhgRU
(ssh-ed25519)
Password: False
Keytab: True
Managed by: client.lab.example.net

Note that enrolled hosts have a Keytab assigned. Keytab files are discussed later in
the Kerberos section.
8.4. Run the ipa-join --unenroll command.

[root@client ~]# ipa-join --unenroll

Unenrollment successful.

8.5. Use the ipa host-show command to view the host record for client again.

[root@client ~]# ipa host-show client.lab.example.net

Note that unenrolling a host simply removes the Keytab in the clients host record,
but no changes are made to the client machine.
8.6. Run the ipa-join command to rejoin the domain.

[root@client ~]# ipa-join

Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=LAB.EXAMPLE.NET
[root@client ~]# logout

70 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

[student@client ~]$ logout

[student@workstation ~]$

Cleanup
From workstation, run the lab manage-clients cleanup command to clean up this
exercise.

[student@workstation ~]$ lab manage-clients cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 71
CHAPTER 2 | Centralizing Identity Management

PROGRAMMING WITH THE MANAGEMENT

INTERFACE

OBJECTIVES
After completing this section, students should be able to:

• Connect to the Management Interface using the curl command.

• Connect to the Management Interface using the IdM server web console.

• Query user and host objects.

INTRODUCTION TO THE IDM MANAGEMENT

INTERFACE
By providing a management interface, third-party products can integrate with an IdM server, using
the same methods as the web UI and the ipa command-line utility.

The Web UI, written in JavaScript, runs in the local browser. It communicates with the management
framework using JSON-RPC. Beginning with version 4, the ipa command line client can also use
JSON-RPC. In previous versions, the protocol used was XML-RPC.

The management framework, written in Python, provides a single application to manage various
IdM server components, such as the directory server, security certificates, and DNS.

THE JSON REQUEST AND RESPONSE SEQUENCE

The IdM management framework implements an extended version of JSON-RPC version 1.0. Data
that is passed between the client and server is serialized as JSON, meaning that it is translated
into a JSON object for transmission then reconstruction. Conversation between a client and the
management framework uses the following sequence:

1. The client sends a POST request to the appropriate authentication endpoint. There are two
endpoints available: /ipa/session/login_kerberos for Kerberos authentication, and /
ipa/session/login_password for user name and password authentication. If Kerberos
authentication is required, the client must first authenticate to IdM, then use the Negotiate
authentication method during the request. If authentication with a user name and password is
required, the credentials must be sent in the form-urlencoded form as part of the request.

2. The management framework validates the authentication information with its database. If
successful, the server responds with an authentication token to store in a cookie.

3. The client sends a request to the JSON endpoint, /ipa/session/json, to perform the
desired task. It must include the authentication token with the request.

4. The request is parsed, and then dispatched for processing.

5. The request result and relevant data is serialized as JSON and returned to the client.

NOTE
For more information on the IdM API, consult the knowledge base on Using the
Identity Management API to Communicate with the IdM Server (Technology Preview)
listed in the references section.

72 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Requests
A request is a single object, sent from a client to a server, with the data serialized as JSON. The
following table describes the properties that must be present:

REQUEST PROPERTIES

id A positive integer value to uniquely identify this request.

method The command for the management framework to execute.

params An array of options to the method being invoked. This includes

options that are unique to the method, as well as common options.

The following is an example request payload for the env method:

{
"id": 0,
"method": "env",
"params": [
[],
{
"server": true,
"all": true
}
]
}

NOTE
The IdM management framework expects the version property to be present in the
request. If you do not provide it, the server still processes your request but adds a
warning to the response.

NOTE
The IdM management framework expects the Referer header to be set
when sending requests. The header must be set to the base URL for the IdM
server API. In this classroom, the Referer header value reads https://
idm.lab.example.net/ipa.

Responses
When execution of the method provided in the request is complete, the results are serialized as
JSON and returned to the client.

RESPONSE PROPERTIES

id An integer matching this result to its request.

error An object containing error information if an error occurred, null

otherwise.

principal The user that executed the method.

RH362-RHEL-7.4-en-1-20181003 73
CHAPTER 2 | Centralizing Identity Management

RESPONSE PROPERTIES

result A nested object containing the results of the method call.

The content of this property varies depending on the method
called, but may include the following items:

• messages: any messages from the server

• result: information returned by the method
• summary: a summary of the result
• value: the object affected

The following shows a response payload:

...output omitted...
"error": null,
"id": 0,
"principal": "admin@LAB.EXAMPLE.NET",
"result": {
"messages": [
{
"code": 13001,
"data": {
"server_version": "2.228"
},
"message": "API Version number was not sent, forward compatibility
not guaranteed. Assuming server's API version, 2.228",
"name": "VersionMissing",
"type": "warning"
}
],
"result": {
"gidnumber": [
"852200000"
],
...output omitted...
},
"summary": "Modified user \"admin\"",
"value": "admin"
},
"version": "4.5.0"
}

STRUCTURE OF IDM COMMANDS

IdM commands are structured into topics. A topic represents a set of operations related to the
same object type. For example, the cert topic includes certificate-related commands, and the group
topic includes group-related commands. Commands within the IdM framework are represented by
specifying the following:

• A topic, such as user, group, or host.

• An operation, such as add, mod, or del.

Some common operations, such as add, modify, or delete, are available for multiple topics.
For example, it is possible to add users, certificates, hosts, and a number of other objects. IdM
distinguishes two types of commands:

74 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

• Methods: Commands that operate on an LDAP object. A method always has an associated LDAP
object.
• Commands: Commands that do not have associated LDAP objects.

For instance, certificates are usually stored in other LDAP objects as an attribute value, but do not
have their own LDAP object. Therefore, commands that modify certificates are not methods, but
commands.

You can view ipa request and response JSON payloads in a pretty-printed format by using the -
vv option:

[user@demo ~]$ ipa -vv user-show admin

...output omitted...
ipa: INFO: Request: {
"id": 0,
"method": "user_show/1",
"params": [
[
"admin"
],
{
"version": "2.228"
}
]
}
ipa: INFO: Response: {
"error": null,
"id": 0,
"principal": "admin@LAB.EXAMPLE.NET",
"result": {
"result": {
"dn": "uid=admin,cn=users,cn=accounts,dc=lab,dc=example,dc=net",
"gidnumber": [
"852200000"
],
"has_keytab": true,
"has_password": true,
"homedirectory": [
"/home/admin"
],
"krbprincipalname": [
"admin@LAB.EXAMPLE.NET"
],
"loginshell": [
"/bin/bash"
],
"memberof_group": [
"admins",
"trust admins"
],
"nsaccountlock": false,
"sn": [
"Administrator"
],
"uid": [
"admin"

RH362-RHEL-7.4-en-1-20181003 75
CHAPTER 2 | Centralizing Identity Management

],
"uidnumber": [
"852200000"
]
},
"summary": null,
"value": "admin"
},
"version": "4.5.0"
}
...output omitted...

STRUCTURE OF JSON-RPC COMMANDS

In JSON-RPC, methods and commands are called using the topic_operation format. For
example:

• user_add
• user_mod
• user_del

The options and arguments to the method or command are provided in the params property of
the request. Arguments are contained in an array, and options are contained in a dictionary. In the
following excerpt, admin is the uid argument. rights and all are options.

...output omitted...
"params": [
[
"admin"
],
{
"rights": true,
"all": true
}
]
...output omitted...

EXAMPLE OF JSON-RPC REQUESTS USING curl

The following example shows the syntax for authenticating to IdM using the curl command. It
provides the user name and password, and uses the /ipa/session/login_password endpoint.
The authentication cookie is stored in ~/idm_cookies.txt, and the Referer header is also set.

curl -s -S -k \
-H "Referer:https://idm.lab.example.net/ipa" \
-H "Content-Type:application/x-www-form-urlencoded" \
-H "Accept:text/plain" \
-X POST \
-d "user=admin&password=RedHat123^" \
-c ~/idm_cookies.txt -b ~/idm_cookies.txt \
https://idm.lab.example.net/ipa/session/login_password

76 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

BROWSING API METHODS

To view available methods and their associated arguments and options, the IdM web UI
provides an API browser. In a web browser, open the IdM web interface accessible at https://
idm.lab.example.net. Log in as the admin user, with the password RedHat123^.

Once logged in, you can find additional information by navigating to IPA Server → API Browser.
Use the filter field at the top of the left pane to restrict the list to methods with matching names.

Figure 2.8: The IdM API Browser

PROGRAMMING WITH THE MANAGEMENT INTERFACE

1. Authenticate to IdM.

2. Execute the idm command to show all attributes for the demo user. Use the -vv to show the
request and response payloads in JSON format.

3. Authenticate to the IdM API using the curl command.

4. Perform the request using the curl command and the req_show_demo.json file.

REFERENCES
Further information is available in the knowledge base on Using the Identity
Management API to Communicate with the IdM Server (Technology Preview) at
https://access.redhat.com/articles/2728021

JSON-RPC v1.0 speciﬁcation

http://www.jsonrpc.org/specification_v1

RH362-RHEL-7.4-en-1-20181003 77
CHAPTER 2 | Centralizing Identity Management

GUIDED EXERCISE

PROGRAMMING WITH THE MANAGEMENT

INTERFACE
In this exercise, you will perform queries against the IdM Management Interface.

OUTCOMES
You should understand the basics of communicating with IdM using the Management
Interface.

Log in to workstation as the student user, then open a terminal and execute the lab
manage-api setup command. The command ensures that the classroom is ready for this
exercise.

[student@workstation ~]$ lab manage-api setup

1. Authenticate to the IdM Management Interface using the curl command. As

workstation is not joined to the IdM domain, you are prompted for a username and
password authentication rather than a Kerberos authentication. Inspect the cookie file when
authenticated.

OPTIONS, DATA, AND HEADERS

Username admin

Password RedHat123^

Referer https://idm.lab.example.net/ipa

Content-Type application/x-www-form-urlencoded

Accept text/plain

Cookie ﬁle /home/student/idm_cookies.txt

API endpoint https://idm.lab.example.net/ipa/session/

login_password

NOTE
Optionally, copy and paste the content of the text file located at /home/student/
RH362/labs/central-api/curl-command1.txt.

[student@workstation ~]$ curl -s -S -k \

-H "Referer:https://idm.lab.example.net/ipa" \
-H "Content-Type:application/x-www-form-urlencoded" \
-H "Accept:text/plain" \

78 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

-X POST \
-d "user=admin&password=RedHat123^" \
-c ~/idm_cookies.txt -b ~/idm_cookies.txt \
https://idm.lab.example.net/ipa/session/login_password
[student@workstation ~]$ cat ~/idm_cookies.txt
# Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_idm.lab.example.net FALSE /ipa TRUE 0 ipa_session

MagBearerToken=X1GhubPfxLpmMNUK9FszHXytnRJN1acyj9KfDMAss9gB5zwT
%2fwD0NxSDK6dlxZfWSgbkKrwJor
%2bIX1cs7K0OzD2lk7E3a5dYzyYZIZ5cAdf9isDYJ6asUxyCC4Svm4hczE40UmtVThDXZ%2fmGnXS
%2fxopJkvfflMWiWY7anNV%2fx1HFp5HwsGAFPfspO8UKanKJzmA5IZO8ieofZ7TnadDBTA%3d%3d

2. Show the details for the admin user. The JSON request payload is /home/student/
req_show_admin.json. Use the -d @<file_name> option to provide the payload as
a file rather than a string. Pipe the curl output to python -m json.tool for pretty
printing.

OPTIONS, DATA, AND HEADERS

Referer https://idm.lab.example.net/ipa

Content-Type application/json

Accept application/json

cookie ﬁle /home/student/idm_cookies.txt

JSON request /home/student/req_show_admin.json

API endpoint https://idm.lab.example.net/ipa/session/

json

NOTE
Optionally, copy and paste the content of the text file located at /home/student/
RH362/labs/central-api/curl-command2.txt.

[student@workstation ~]$ curl -s -S -k \

-H "Referer:https://idm.lab.example.net/ipa" \
-H "Content-Type:application/json" \
-H "Accept:application/json" \
-X POST \
-d @req_show_admin.json \
-c ~/idm_cookies.txt -b ~/idm_cookies.txt \
https://idm.lab.example.net/ipa/session/json \
| python -m json.tool
...output omitted...
"result": {
"dn": "uid=admin,cn=users,cn=accounts,dc=lab,dc=example,dc=net",
"gidnumber": [
"852200000"

RH362-RHEL-7.4-en-1-20181003 79
CHAPTER 2 | Centralizing Identity Management

],
"has_keytab": true,
"has_password": true,
"homedirectory": [
"/home/admin"
],
"krbprincipalname": [
"admin@LAB.EXAMPLE.NET"
],
"loginshell": [
"/bin/bash"
],
"memberof_group": [
"admins",
"trust admins"
],
"nsaccountlock": false,
"sn": [
"Administrator"
],
"uid": [
"admin"
],
"uidnumber": [
"852200000"
]
},
...output omitted...

3. Copy an SSH public key into the JSON request payload file. Add the public key to the admin
user account.
3.1. Copy the content of /home/student/.ssh/lab_rsa.pub into /home/
student/req_mod_admin.json.

NOTE
The SSH public key data should not contain any carriage returns.

...output omitted...
{
"setattr": "ipasshpubkey=ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDGtUW3ismHyuCW4CDdTVOOOq6aySdtYenX
FWWx7HJa4VTepkG00aaLId9ocra10hc+MB0GTJMCyabDv3i8NKdi6GDH/aOLVsp/
Ewy8DEzZMBlJDCt4v2i4/wU4liw6KgEFkZs+5hnqU8d4QzldyGJ5onr+AGvFOKG6
8CS0BBl40Z1twf1HhCyx8k6nzD2ovlkxWRFZKPAFrtPCBVvQDkOfVFZF+lwzaSzt
gAjbFZ4A9jqQyUYx4kOJ5DtRef36ucdUdVQale0+8lICl7/gb142SPpYfhxe88/B
JScLPRjvVNeu1TxRmoHtVazqnAoRxQYAn2MoI6AG+w6QuZf8f7aL LabGradingKey"
}

80 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

...output omitted...

3.2. Add the SSH public key to the admin user.

OPTIONS, DATA, AND HEADERS

Referer https://idm.lab.example.net/ipa

Content-Type application/json

Accept application/json

Cookie ﬁle /home/student/idm_cookies.txt

JSON request /home/student/req_mod_admin.json

API endpoint https://idm.lab.example.net/ipa/

session/json

NOTE
Optionally, copy and paste the content of the text file located at /home/student/
RH362/labs/central-api/curl-command3.txt.

[student@workstation ~]$ curl -s -S -k \

-H "Referer:https://idm.lab.example.net/ipa" \
-H "Content-Type:application/json" \
-H "Accept:application/json" \
-X POST \
-d @req_mod_admin.json \
-c ~/idm_cookies.txt -b ~/idm_cookies.txt \
https://idm.lab.example.net/ipa/session/json \
| python -m json.tool
...output omitted...
"has_password": true,
"homedirectory": [
"/home/admin"
],
"ipasshpubkey": [
"ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDGtUW3ismHyuCW4CDdTVOOOq6aySdtY
enXFWWx7HJa4VTepkG00aaLId9ocra10hc+MB0GTJMCyabDv3i8NKdi6GDH/a
OLVsp/Ewy8DEzZMBlJDCt4v2i4/wU4liw6KgEFkZs+5hnqU8d4QzldyGJ5onr
+AGvFOKG68CS0BBl40Z1twf1HhCyx8k6nzD2ovlkxWRFZKPAFrtPCBVvQDkOf
VFZF+lwzaSztgAjbFZ4A9jqQyUYx4kOJ5DtRef36ucdUdVQale0+8lICl7/gb
142SPpYfhxe88/BJScLPRjvVNeu1TxRmoHtVazqnAoRxQYAn2MoI6AG+w6QuZ
f8f7aL LabGradingKey"
],
"krbprincipalname": [
"admin@LAB.EXAMPLE.NET"
],
...output omitted...
"nsaccountlock": false,
"sn": [

RH362-RHEL-7.4-en-1-20181003 81
CHAPTER 2 | Centralizing Identity Management

"Administrator"
],
"sshpubkeyfp": [
"SHA256:M8ikhcEDm2tQ95Z0o7ZvufqEixCFCt+wowZLNzNlBT0 LabGradingKey
(ssh-rsa)"
],
"uid": [
"admin"
],
...output omitted...

4. Display the server environment variables.

OPTIONS, DATA, AND HEADERS

Referer https://idm.lab.example.net/ipa

Content-Type application/json

Accept application/json

Cookie ﬁle /home/student/idm_cookies.txt

JSON request /home/student/req_env.json

API endpoint https://idm.lab.example.net/ipa/session/

json

NOTE
Optionally, copy and paste the content of the text file located at /home/student/
RH362/labs/central-api/curl-command4.txt.

[student@workstation ~]$ curl -s -S -k \

-H "Referer:https://idm.lab.example.net/ipa" \
-H "Content-Type:application/json" \
-H "Accept:application/json" \
-X POST \
-d @req_env.json \
-c ~/idm_cookies.txt -b ~/idm_cookies.txt \
https://idm.lab.example.net/ipa/session/json \
| python -m json.tool
...output omitted...
"result": {
"api_version": "2.228",
"basedn": "dc=lab,dc=example,dc=net",
"bin": "/",
"ca_agent_install_port": null,
"ca_agent_port": 443,
"ca_ee_install_port": null,
"ca_ee_port": 443,
"ca_host": "idm.lab.example.net",
"ca_install_port": null,
"ca_port": 80,

82 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

"conf": "/etc/ipa/server.conf",
"conf_default": "/etc/ipa/default.conf",
"confdir": "/etc/ipa",
"config_loaded": true,
"container_accounts": "cn=accounts",
"container_adtrusts": "cn=ad,cn=trusts",
"container_applications": "cn=applications,cn=configs,cn=policies",
"container_automember": "cn=automember,cn=etc",
"container_automount": "cn=automount",
"container_ca": "cn=cas,cn=ca",
"container_caacl": "cn=caacls,cn=ca",
"container_certmap": "cn=certmap",
"container_certmaprules": "cn=certmaprules,cn=certmap",
"container_certprofile": "cn=certprofiles,cn=ca",
"container_cifsdomains": "cn=ad,cn=etc",
"container_configs": "cn=configs,cn=policies",
"container_custodia": "cn=custodia,cn=ipa,cn=etc",
"container_deleteuser": "cn=deleted
users,cn=accounts,cn=provisioning",
"container_dna": "cn=dna,cn=ipa,cn=etc",
"container_dna_posix_ids": "cn=posix-ids,cn=dna,cn=ipa,cn=etc",
"container_dns": "cn=dns",
"container_dnsservers": "cn=servers,cn=dns",
"container_group": "cn=groups,cn=accounts",
"container_hbac": "cn=hbac",
"container_hbacservice": "cn=hbacservices,cn=hbac",
"container_hbacservicegroup": "cn=hbacservicegroups,cn=hbac",
"container_host": "cn=computers,cn=accounts",
"container_hostgroup": "cn=hostgroups,cn=accounts",
"container_locations": "cn=locations,cn=etc",
"container_masters": "cn=masters,cn=ipa,cn=etc",
"container_netgroup": "cn=ng,cn=alt",
"container_otp": "cn=otp",
"container_permission": "cn=permissions,cn=pbac",
"container_policies": "cn=policies",
"container_policygroups": "cn=policygroups,cn=configs,cn=policies",
"container_policylinks": "cn=policylinks,cn=configs,cn=policies",
"container_privilege": "cn=privileges,cn=pbac",
"container_radiusproxy": "cn=radiusproxy",
"container_ranges": "cn=ranges,cn=etc",
"container_realm_domains": "cn=Realm Domains,cn=ipa,cn=etc",
"container_rolegroup": "cn=roles,cn=accounts",
"container_roles": "cn=roles,cn=policies",
"container_s4u2proxy": "cn=s4u2proxy,cn=etc",
"container_selinux": "cn=usermap,cn=selinux",
"container_service": "cn=services,cn=accounts",
"container_stageuser": "cn=staged users,cn=accounts,cn=provisioning",
"container_sudocmd": "cn=sudocmds,cn=sudo",
"container_sudocmdgroup": "cn=sudocmdgroups,cn=sudo",
"container_sudorule": "cn=sudorules,cn=sudo",
"container_sysaccounts": "cn=sysaccounts,cn=etc",
"container_topology": "cn=topology,cn=ipa,cn=etc",
"container_trusts": "cn=trusts",
"container_user": "cn=users,cn=accounts",
"container_vault": "cn=vaults,cn=kra",
"container_views": "cn=views,cn=accounts",

RH362-RHEL-7.4-en-1-20181003 83
CHAPTER 2 | Centralizing Identity Management

"container_virtual": "cn=virtual operations,cn=etc",

"context": "server",
"debug": false,
"delegate": false,
"dogtag_version": 10,
"domain": "lab.example.net",
"dot_ipa": "/.ipa",
"enable_ra": true,
"env_confdir": null,
"fallback": true,
"fips_mode": false,
"force_schema_check": false,
"home": "/",
"host": "idm.lab.example.net",
"in_server": true,
"in_tree": false,
"interactive": true,
"ipalib": "/usr/lib/python2.7/site-packages/ipalib",
"jsonrpc_uri": "https://idm.lab.example.net/ipa/json",
"kinit_lifetime": null,
"ldap_uri": "ldapi://%2fvar%2frun%2fslapd-LAB-EXAMPLE-NET.socket",
"log": null,
"logdir": "/var/log/ipa",
"mode": "production",
"mount_ipa": "/ipa/",
"nss_dir": "/etc/ipa/nssdb",
"plugins_on_demand": false,
"prompt_all": false,
"ra_plugin": "dogtag",
"realm": "LAB.EXAMPLE.NET",
"recommended_max_agmts": 4,
"rpc_protocol": "jsonrpc",
"script": "/mod_wsgi",
"server": "idm.lab.example.net",
"session_auth_duration": "20 minutes",
"session_duration_type": "inactivity_timeout",
"site_packages": "/usr/lib/python2.7/site-packages",
"skip_version_check": false,
"startup_timeout": 300,
"startup_traceback": false,
"tls_ca_cert": "/etc/ipa/ca.crt",
"tls_version_max": "tls1.2",
"tls_version_min": "tls1.0",
"validate_api": false,
"verbose": 0,
"version": "4.5.0",
"wait_for_dns": 0,
"webui_prod": true,
"xmlrpc_uri": "https://idm.lab.example.net/ipa/xml"
},
...output omitted...

5. Use a web browser to open https://idm.lab.example.net, then log in as user admin

and password RedHat123^. Navigate to IPA Server → API Browser, type user_mod in the
filter field, then select user_mod from the list. Note the Arguments, Options, and Common
Options available for this method.

84 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Cleanup
From workstation, run the lab manage-api cleanup command to clean up this exercise.

[student@workstation ~]$ lab manage-api cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 85
CHAPTER 2 | Centralizing Identity Management

LAB

CENTRALIZING IDENTITY MANAGEMENT

PERFORMANCE CHECKLIST
In this lab, you will unenroll a previously registered client and then enroll it back. You will
create a set of IdM resources, such as users and groups. Finally, you will log in to the client to
ensure proper configuration of the IdM server.

OUTCOMES
You should be able to:

• Uninstall and unenroll client, a previously registered client in the IdM server.

• Enroll the client client to the IdM server.

• Create users, groups, and policies in IdM.

• Log in to the client with the users created in the IdM server.

Log in to workstation as student using student as the password. Run the lab manage-
review setup command. The script creates the required resources for the activity and ensures
that the IdM environment is properly running.

[student@workstation ~]$ lab manage-review setup

1. From workstation, open a terminal to log in to client as the root user. Uninstall the
client to unenroll it and remove it from the IdM domain, along with all of the IdM-specific
configuration. When prompted, do not reboot the server. Finally, remove the ipa-client
package.
2. On client, install the ipa-client package. Use the nmcli command to assign the eth0
network interface the IP address of 172.25.250.9 as the DNS server and bring up the
interface.
3. Configure the client VM as a client in the unattended mode. Provide a user name of admin
and a password of RedHat123^. Upon enrollment, verify that you can log in to the IdM server
by retrieving a ticket as the admin user. The admin user has a password of RedHat123^.

NOTE
Use the --force-join option if the enrollment fails.

4. Create users in IdM according to the following table. For the idmuser04, provide the SSH
public key available at /root/RH362/labs/manage-review/lab-pub.key on the
client VM. Upon the creation of the staged user, idmuser04, set it as an active user.
Disable the idmuser05 account, and delete the idmuser10 user.

86 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

USER NAME ACCOUNT TYPE FIRST LAST PASSWORD

NAME NAME

idmuser04 Staged user04 idm redhat

idmuser05 Active user05 idm redhat

5. Create the idmgroup01 group with a description of Devops Group and add the
idmuser04 user to the group.
Retrieve the list of groups and delete the idmgroup02 group.
6. Update the global password policy according to the following specifications:

• Minimum password length: 8 characters

• Lockout time: 20 minutes

• Maximum number of password failures: 5

Create the idmgroup10 password policy with a minimum password length of eight
characters and a priority of 1.
7. From the workstation VM, open a new terminal and log in to the client VM using
idmuser04 as the user name and redhat as the password. When logged in, update the
password using r3d4t as the new password choice. Update the password again, this time use
redh@t123! as the new password choice. Finally, exit from the server.
8. From the workstation VM, open a new terminal and log in to the client VM using
idmuser05 as the user name. The command should fail as the user is inactive. Enable the
user and add it to the idmgroup01 group.
Log in to client as the idmuser05 and update the password with r3d4t, then generate a
password by running the following command:

-sh-4.2$ openssl rand -base64 8

Finally, exit from the server.

From the workstation VM, run the lab manage-review grade command to grade your work.

[student@workstation ~]$ lab manage-review grade

From the workstation VM, run the lab manage-review cleanup command to clean up the
activity.

[student@workstation ~]$ lab manage-review cleanup

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 87
CHAPTER 2 | Centralizing Identity Management

SOLUTION

CENTRALIZING IDENTITY MANAGEMENT

OUTCOMES
You should be able to:

• Uninstall and unenroll client, a previously registered client in the IdM server.

• Enroll the client client to the IdM server.

• Create users, groups, and policies in IdM.

• Log in to the client with the users created in the IdM server.

[student@workstation ~]$ lab manage-review setup

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

1.2. Run the ipa-client-install command with the --uninstall option to uninstall
the client.

[root@client ~]# ipa-client-install --uninstall

Unenrolling client from IPA server
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/
sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration

88 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

nslcd daemon is not installed, skip configuration

Systemwide CA database updated.
Client uninstall complete.
The original nsswitch.conf configuration has been restored.
You may need to restart services or reboot the machine.
Do you want to reboot the machine? [no]: Enter
The ipa-client-install command was successful

1.3. Run the yum command to remove the ipa-client package.

[root@client ~]# yum remove ipa-client

...output omitted...
Installed size: 250 k
Is this ok [y/N]: y
...output omitted...
Removed:
ipa-client.x86_64 0:4.5.0-20.el7

Complete!

2. On client, install the ipa-client package. Use the nmcli command to assign the eth0
network interface the IP address of 172.25.250.9 as the DNS server and bring up the
interface.
2.1. On client, install the ipa-client package.

[root@client ~]# yum install ipa-client

...output omitted...
Installed size: 250 k
Is this ok [y/d/N]: y
...output omitted...
Complete!

2.2. Use the nmcli command to specify a DNS address of 172.25.250.8 to the eth0
network device. Bring up the interface.

[root@client ~]# nmcli connection modify "System eth0" \

ipv4.dns 172.25.250.8
[root@client ~]# nmcli connection up "System eth0"

3. Configure the client VM as a client in the unattended mode. Provide a user name of admin
and a password of RedHat123^. Upon enrollment, verify that you can log in to the IdM server
by retrieving a ticket as the admin user. The admin user has a password of RedHat123^.

NOTE
Use the --force-join option if the enrollment fails.

3.1. From the client VM, run the ipa-client-install command to configure the
client.
Install the client in unattended mode, use a principal of admin and a password of
RedHat123^. Enable the creation of users home directories.

[root@client ~]# ipa-client-install \

RH362-RHEL-7.4-en-1-20181003 89
CHAPTER 2 | Centralizing Identity Management

--principal admin \
--password RedHat123^ \
--mkhomedir \
--unattended
WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

Discovery was successful!

Client hostname: client.lab.example.net
Realm: LAB.EXAMPLE.NET
DNS Domain: lab.example.net
IPA Server: idm.lab.example.net
BaseDN: dc=lab,dc=example,dc=net
...output omitted...
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring lab.example.net as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

3.2. Authenticate against the IdM server by running the kinit command. Use admin as
the password. Upon authentication, run the klist command to ensure that the ticket
is successfully issued.

[root@client ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^
[root@client ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

21/02/18 14:43:45 22/02/18 14:43:44 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

USER NAME ACCOUNT TYPE FIRST LAST PASSWORD

NAME NAME

idmuser04 Staged user04 idm redhat

idmuser05 Active user05 idm redhat

4.1. From the client VM, create the staged user idmuser04 with a password of redhat.
Import the SSH public key available at /root/RH362/labs/manage-review/lab-
pub.key

[root@client ~]# ipa stageuser-add idmuser04 \

--first=user04 --last=idm \
--sshpubkey="$(cat /root/RH362/labs/manage-review/lab-pub.key)" \
--password
90 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Password: redhat
Enter Password again to verify: redhat
----------------------------
Added stage user "idmuser04"
----------------------------
User login: idmuser04
First name: user04
Last name: idm
Full name: user04 idm
Display name: user04 idm
Initials: IU
Home directory: /home/idmuser04
GECOS: user04 idm
Login shell: /bin/sh
Principal name: idmuser04@LAB.EXAMPLE.NET
Principal alias: idmuser04@LAB.EXAMPLE.NET
Email address: idmuser04@lab.example.net
...output omitted...

4.2. From the client VM, create the staged user idmuser05 with a password of redhat.

[root@client ~]# ipa user-add idmuser05 \

--first=user05 --last=idm \
--password
Password: redhat
Enter Password again to verify: redhat
----------------------------
Added stage user "idmuser05"
----------------------------
User login: idmuser05
First name: user05
Last name: idm
Full name: user05 idm
Display name: user05 idm
Initials: IU
Home directory: /home/idmuser05
GECOS: user05 idm
Login shell: /bin/sh
Principal name: idmuser05@LAB.EXAMPLE.NET
Principal alias: idmuser05@LAB.EXAMPLE.NET
Email address: idmuser05@lab.example.net
...output omitted...

4.3. Set the idmuser04 as an active user.

[root@client ~]# ipa stageuser-activate idmuser04

------------------------------
Stage user idmuser04 activated
------------------------------
...output omitted...

Disable the idmuser05 account.

[root@client ~]# ipa user-disable idmuser05

---------------------------------

RH362-RHEL-7.4-en-1-20181003 91
CHAPTER 2 | Centralizing Identity Management

Disabled user account "idmuser05"

---------------------------------

4.4. Delete the idmuser10 account.

[root@client ~]# ipa user-del idmuser10

------------------------
Deleted user "idmuser10"
------------------------

5. Create the idmgroup01 group with a description of Devops Group and add the
idmuser04 user to the group.
Retrieve the list of groups and delete the idmgroup02 group.
5.1. From the client VM, create the idmgroup01 group. Give the group a description of
Devops Group.

[root@client ~]# ipa group-add idmgroup01 \

--desc "Devops Group"
------------------------
Added group "idmgroup01"
------------------------
Group name: idmgroup01
Description: Devops Group
GID: 408400020

5.2. Add the idmuser04 user to the idmgroup01 group.

[root@client ~]# ipa group-add-member idmgroup01 \

--users=idmuser04
Group name: idmgroup01
Description: Devops Group
GID: 408400020
Member users: idmuser04
-------------------------
Number of members added 1
-------------------------

5.3. List the available groups.

[root@client ~]# ipa group-find

----------------
7 groups matched
----------------
Group name: admins
Description: Account administrators group
GID: 408400000

Group name: editors

Description: Limited admins who can edit other users
GID: 408400002

Group name: idmgroup01

Description: Devops Group
GID: 408400020

92 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

Group name: idmgroup02

Description: Delete Me
GID: 408400021

Group name: idmgroup10

Description: Idm Group10
GID: 408400022

Group name: ipausers

Description: Default group for all users

Group name: trust admins

Description: Trusts administrators group
----------------------------
Number of entries returned 7
----------------------------

5.4. Delete the idmgroup02 group.

[root@client ~]# ipa group-del idmgroup02

--------------------------
Deleted group "idmgroup02"
--------------------------

6. Update the global password policy according to the following specifications:

• Minimum password length: 8 characters

• Lockout time: 20 minutes

• Maximum number of password failures: 5

Create the idmgroup10 password policy with a minimum password length of eight
characters and a priority of 1.
6.1. From the client VM, update the global password policy according to the
specifications defined in the previous list.

[root@client ~]# ipa pwpolicy-mod \

--minlength=8 \
--lockouttime=1200 \
--maxfail 5
Group: global_policy
Max lifetime (days): 90
Min lifetime (hours): 1
History size: 0
Character classes: 0
Min length: 8
Max failures: 5
Failure reset interval: 60
Lockout duration: 1200

6.2. Create idmgroup10 password policy with a minimum password length of eight
characters and a priority of 1.

[root@client ~]# ipa pwpolicy-add idmgroup10 \

--minlength 8 --priority 1

RH362-RHEL-7.4-en-1-20181003 93
CHAPTER 2 | Centralizing Identity Management

Group: idmgroup10
Min length: 8
Priority: 1

6.3. Add user idmuser04 to the idmgroup10 group that has the newly created password
policy applied to the group.

[root@client ~]# ipa group-add-member idmgroup10 --users=idmuser04

Group name: idmgroup10
Description: Idm Group 10
GID: 134600019
Member users: idmuser04
-------------------------
Number of members added 1
-------------------------

7. From the workstation VM, open a new terminal and log in to the client VM using
idmuser04 as the user name and redhat as the password. When logged in, update the
password using r3d4t as the new password choice. Update the password again, this time use
redh@t123! as the new password choice. Finally, exit from the server.
7.1. From workstation, open a new terminal and log in to client as the idmuser04
user. When prompted, use a password of redhat.

[student@workstation ~]$ ssh idmuser04@client

Creating home directory for idmuser04.
-sh-4.2$

7.2. Update the password for the idmuser04 user by using r3d4t. The password is
refused due to the password policy.

-sh-4.2$ passwd
Changing password for user idmuser04.
Current Password: redhat
New password: r3d4t
Retype new password: r3d4t
Password change failed. Server message: Password is too short

Password not changed.

passwd: Authentication token manipulation error

7.3. Retry with a password of redh@t123!.

-sh-4.2$ passwd
Changing password for user idmuser04.
Current Password: redhat
New password: redh@t123!
Retype new password: redh@t123!
passwd: all authentication tokens updated successfully.

7.4. Exit the from the server.

-sh-4.2$ exit
[student@workstation ~]$

94 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

8. From the workstation VM, open a new terminal and log in to the client VM using
idmuser05 as the user name. The command should fail as the user is inactive. Enable the
user and add it to the idmgroup01 group.
Log in to client as the idmuser05 and update the password with r3d4t, then generate a
password by running the following command:

-sh-4.2$ openssl rand -base64 8

Finally, exit from the server.

8.1. From workstation, open a new terminal and log in to client as the idmuser05
user.

[student@workstation ~]$ ssh idmuser05@client

Authentication failed.

8.2. Log in to the client VM as the student user, become root then enable the
idmuser05 user.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]# ipa user-enable idmuser05
--------------------------------
Enabled user account "idmuser05"
--------------------------------

8.3. Add the idmuser05 to the idmgroup10 group.

[root@client ~]# ipa group-add-member idmgroup10 \

--users=idmuser05
Group name: idmgroup10
Description: Idm Group 10
GID: 134600029
Member users: idmuser04, idmuser05
-------------------------
Number of members added 1
-------------------------

8.4. Exit from client.

8.5. From the workstation VM, log in to client as the idmuser05 user. When logged
in, update the password by using r3d47

[student@workstation ~]$ ssh idmuser05@client

Creating home directory for idmuser05.
-sh-4.2$ passwd
Changing password for user idmuser05.
Current Password: redhat
New password: r3d47
Retype new password: r3d47
Password change failed. Server message: Password is too short

Password not changed.

RH362-RHEL-7.4-en-1-20181003 95
CHAPTER 2 | Centralizing Identity Management

passwd: Authentication token manipulation error

8.6. Generate an eight-characters password with the openssl command. Copy the output
to your clipboard use it as the new user password.

-sh-4.2$ openssl rand -base64 8

JZDhjprLzqY=
-sh-4.2$ passwd
Changing password for user idmuser05.
Current Password: redhat
New password: JZDhjprLzqY=
Retype new password: JZDhjprLzqY=
passwd: all authentication tokens updated successfully.

8.7. Exit from the server.

From the workstation VM, run the lab manage-review grade command to grade your work.

[student@workstation ~]$ lab manage-review grade

From the workstation VM, run the lab manage-review cleanup command to clean up the
activity.

[student@workstation ~]$ lab manage-review cleanup

This concludes the lab.

96 RH362-RHEL-7.4-en-1-20181003
CHAPTER 2 | Centralizing Identity Management

SUMMARY

In this chapter, you learned:

• The IdM command-line tools include the ipactl, kinit, klist, and ipa commands. Most
management tasks can also be performed using the IdM web UI. The ipa subcommands take the
form object-action, where common actions include add, mod, del, show, and find.

• IdM clients can be installed interactively or unattended. IdM also supports non-Linux clients. The
IdM client software does not use a daemon, it configures standard software such as Kerberos,
LDAP, SSSD, and ntpd.

• The IdM API can be used to integrate third-party scripts and applications, enabling custom
workflows. Request and response data must be in JSON format, as the API uses an extended
JSON-RPC v1.0 protocol. Authentication to the API can be performed using the Negotiate
method for Kerberos authentication, or by passing a username and password.

RH362-RHEL-7.4-en-1-20181003 97
98 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3

AUTHENTICATING IDENTITIES
WITH KERBEROS
GOAL Defining the Kerberos protocol and configuring
services for Kerberos authentication.

OBJECTIVES • Review the authentication process by which

users obtain and validate network credentials to
gain access to services and interfaces.
• Introduce and configure network credentials for
both generic and specific services.
• Configure and use Kerberos authentication
from a remote system that is not an IdM client.
• Manage Kerberos ticketing policies and
maintain principal credentials.

SECTIONS • Introducing Kerberos Authentication (and Quiz)

• Configuring Hosts and Services for Kerberos
(and Guided Exercise)
• Configuring Remote Kerberos Authentication
(and Guided Exercise)
• Managing the Kerberos Domain (and Guided
Exercise)

LAB Authenticating Identities with Kerberos

RH362-RHEL-7.4-en-1-20181003 99
CHAPTER 3 | Authenticating Identities with Kerberos

DEFINING KERBEROS AUTHENTICATION

OBJECTIVES
After completing this section, students should be able to:

• Describe the components for Linux authentication

• Describe and differentiate a principal and a credential

• Contrast the use of symmetric keys for security and asymmetric keys for identity

DESCRIBING KERBEROS COMPONENTS

When IT environments started expanding beyond mainframe computing, user credentials were
often local to each system that a user needed access to. This required manual control of password
complexity and aging polices, and credentials could potentially be different on each system,
requiring users to keep track of several sets of usernames and passwords.

To alleviate this burden, centralized authentication systems were designed. Kerberos is one of the
most successful and mature protocols to have emerged. Now at version 5, it provides benefits such
as Single Sign-on (SSO), no passwords sent over communication channels, mutual authentication,
and allowing authentication between unrelated entities by operating as a trusted third party. The
Kerberos protocol v5 is defined in RFC4120.

There are many terms used in the Kerberos authentication process:

AS
The Authentication Service validates that a user is present in the Kerberos database.

TGS
The Ticket Granting Service provides an authenticated user with a Ticket Granting Ticket.

TGT
A Ticket Granting Ticket is a small, encrypted authentication file with a limited period, used to
obtain session tickets.

Session Ticket
A Session Ticket is a small, encrypted authentication file with a limited period, used to encrypt
communication between two endpoints.

KDC
The Key Distribution Center is the Kerberos server running the AS and TGS services.

realm
The name of a Kerberos domain. The realm name will usually be an uppercase version of the
domain name.

principal
An identity that can be assigned a ticket. A principal uses the following format:
primary[/instance]@REALM.

ticket
A piece of encrypted data representing an authenticated state, also known as a credential. A
ticket may be a Ticket Granting Ticket or a session ticket.

100 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

symmetric key
A key used to encrypt and decrypt a payload.

AES
The Advanced Encryption Standard protocol replaced DES as the preferred symmetric key
protocol.

asymmetric keys
A pair of keys; one used to encrypt, and the other used to decrypt.

keytab
A file containing Kerberos credentials.

Credentials Cache
A credential cache, or ccache stores Kerberos credentials while they remain valid and while
the user’s session lasts. This allows to authenticate against a service multiple times without
contacting the KDC every time.

Kerberos is the core protocol in IdM, providing a Single Sign-On (SSO) capability for IdM users, and
many other features. SSO gives users the ability to transparently authenticate to multiple services
on-demand without providing a password for the lifetime of their Kerberos ticket.

DEFINING KERBEROS PRINCIPALS

In a Kerberos system, all targets involved in authentication (users, hosts, and services) are
represented by a principal. The demo user may have a principal, such as demo@EXAMPLE.COM. A
principal of demo/admin@EXAMPLE.COM is a completely separate credential, usually assigned to
the same user but possibly used for administrative tasks.

A host principal uses host as the primary, fully-qualified host name for the instance; for example,
host/server01.example.com@EXAMPLE.COM.

The primary for service principals is usually a known service such as NFS, HTTPD, or LDAP.
The instance would be set to a DNS name resolvable to the host or hosts providing the
service. The service principal for an example corporate payroll system could be HTTP/
payroll.example.com@EXAMPLE.COM.

KERBEROS KEYTABS
A keytab file is used to store multiple principal keys in the local file system. As there are keys for
each encryption type, and older key versions are kept, you will find multiple keys for a principal
in each keytab. As users are required to type in their passwords at log in, they have no need
of a keytab file. However, hosts and services need credentials when they start, so storing their
credentials locally allows them to start up without human intervention. To see the keys currently
stored in a keytab file, use the klist command with the -k option. You can pass the -e option to
see the encryption type for each key.

[user@demo ~] klist -ke /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- ----------------------------------------------------------------------
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (aes256-cts-hmac-sha1-96)
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (aes128-cts-hmac-sha1-96)
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (des3-cbc-sha1)
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (arcfour-hmac)
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (camellia128-cts-cmac)
2 host/idm.lab.example.net@LAB.EXAMPLE.NET (camellia256-cts-cmac)

RH362-RHEL-7.4-en-1-20181003 101
CHAPTER 3 | Authenticating Identities with Kerberos

AUTHENTICATION PROCESS
The following diagram shows the authentication flow for a user logging in, and authenticating
to a service. The flow in the diagram is not in time order, nor does it cover every aspect of the
interactions.

Kerberos authentication flow

The Authentication Service (AS) on the Key Distribution Center (KDC) maintains account
information for all security principals in the realm, including a cryptographic key derived from
a user's login password. For services, which have no login password, the key is dynamically
generated and stored in the service's keytab file. These credentials were created and stored
by the KDC prior to this figure's step 1. Each principal's cryptographic key is a shared secret
between the KDC and only that principal. To use a Kerberized service, the user first sends a
request to the AS.

To allow the user to gain access to the Ticket Granting Service (TGS), the AS encrypts one
copy of a newly generated session key with the user's shared password key. A second copy
is combined with the user's identity, and encrypted with the Ticket Granting Service's shared
generated key to become a Ticket Granting Ticket (TGT). Both copies are sent to the user, but
only the copy encrypted with user's shared key can be decrypted to retrieve the session key.
The second copy, the TGT, can be decrypted only by the Ticket Granting Service (TGS).

102 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

The user encrypts their identity with the TGS session key. The encrypted identity and
the encrypted TGT from the AS are then sent to the TGS along with a request to access a
particular service. The TGS decrypts the TGT using its private key, and obtains the session key
and the requesting user's identity. The TGS uses the session key to decrypt the identity sent
by the user. The identity sent by the user and the identity encrypted in the TGT by the AS are
then compared. If they match, then the user's TGT is considered valid and the service request
is processed. The same TGT can be used for any future service requests until it expires, then
the user must return to the AS to request a new TGT.

The Ticket Granting Service generates a new session key to be used in a manner similar to
that just described, but this time it allows the user to gain access to the requested Kerberized
service. The TGS encrypts one copy of this service session key with the user's shared
password key. A second copy is combined with the user's identity and encrypted with the
Kerberized service's shared generated key. Both copies are sent to the user, but only the copy
encrypted with the user's shared key can be decrypted, retrieving the service session key. The
second copy can be decrypted only by the Kerberized service.

The user encrypts their identity with the service session key, then sends both the encrypted
identity and the encrypted service session key to the Kerberized service. The service session
key is decrypted first, using Kerberized service principal's shared key from a keytab file, and
also retrieves the requesting user's identity. The Kerberized service uses the service session
key to decrypt the identity sent by the user, then compares the two identities. If they match,
then the user's request is valid and the service request is processed.

The service session key may be used to encrypt data responses, until its expiration is reached,
at which point the user returns to the TGS to request a new service session key, using an
unexpired TGT for proof of identity without returning to the AS for re-authentication.

REFERENCES
Kerberos: An Authentication Service for Computer Networks
http://gost.isi.edu/publications/kerberos-neuman-tso.html

RFC4120: The Kerberos Network Authentication Service (V5)

https://tools.ietf.org/html/rfc4120

Further information is available in the Managing the Kerberos Domain chapter in the
Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

RH362-RHEL-7.4-en-1-20181003 103
CHAPTER 3 | Authenticating Identities with Kerberos

QUIZ

INTRODUCING KERBEROS
AUTHENTICATION
Choose the correct answers to the following questions:

1. A Kerberos principal uses which one of the following formats?

a. username@realm:instance
b. instance:primary\realm
c. primary/[instance]@realm
d. username/hostname@realm

2. Which term is deﬁned as a piece of encrypted data representing an authenticated state,

also known as a credential?
a. asymmetric key
b. principal
c. keytab
d. symmetric key
e. ticket

3. Which two services comprise the KDC? (Choose two.)

a. Ticket Gathering Ticket
b. Ticket Granting Service
c. Encryption Service
d. Ticket Collection Service
e. Authentication Service
f. Authorization Service

4. Which term is deﬁned as an identity that can be assigned a ticket?

a. asymmetric key
b. principal
c. keytab
d. symmetric key
e. ticket

104 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

SOLUTION

INTRODUCING KERBEROS
AUTHENTICATION
Choose the correct answers to the following questions:

1. A Kerberos principal uses which one of the following formats?

a. username@realm:instance
b. instance:primary\realm
c. primary/[instance]@realm
d. username/hostname@realm

2. Which term is deﬁned as a piece of encrypted data representing an authenticated state,

also known as a credential?
a. asymmetric key
b. principal
c. keytab
d. symmetric key
e. ticket

3. Which two services comprise the KDC? (Choose two.)

a. Ticket Gathering Ticket
b. Ticket Granting Service
c. Encryption Service
d. Ticket Collection Service
e. Authentication Service
f. Authorization Service

4. Which term is deﬁned as an identity that can be assigned a ticket?

a. asymmetric key
b. principal
c. keytab
d. symmetric key
e. ticket

RH362-RHEL-7.4-en-1-20181003 105
CHAPTER 3 | Authenticating Identities with Kerberos

CONFIGURING HOSTS AND SERVICES

FOR KERBEROS

OBJECTIVES
After completing this section, students should be able to:

• Describe how and when service credentials are used.

• Compare and contrast user, host (root), and service credentials.

• Describe the contents of a keytab file.

DESCRIBING HOST AND SERVICE PRINCIPALS

All actors in the Kerberos authentication process that require authentication are represented as a
principal. This means that hosts and services are principals, not just users.

When a user communicates with a Kerberized service, the service should use a dedicated service
principal, although some legacy configurations may reuse the host principal. To log in to a host that
is a member of an IdM domain using SSH, sshd uses the host principal as its identifier. The host
principal identifies a specific machine, which for SSH is all that is required.

A service principal may be preferable for several reasons: the service may run on more than one
machine, or a friendly name may be preferred over the host name. Service principals use the
format service-type/hostname@REALM. The service type should match the service being
authenticated, such as HTTP, NFS, or LDAP. The host name is used in the instance position, as there
is no name resolution in Kerberos. A Kerberos-protected intranet site might use a service principal
such as HTTP/intranet.example.com@EXAMPLE.COM.

A host or service credential is stored in a keytab file, and is read by the service when it starts. The
default storage location for a host principal credential is in the /etc/krb5.keytab file. Service
principal keytabs may be stored anywhere that the service has permission to read. Services store
their passwords on the application server in a local keytab file so that they may start up without
human intervention.

Each principal has an associated key used to encrypt tickets. For users, the key is derived from the
user's password. Host and service principals do not have configurable passwords. When they are
created, a random password is generated and the key is derived from that. Hosts and services do
not have the ability to enter passwords interactively, so the key for a host or service principal must
be downloaded and stored in a keytab file instead. The keytab file is similar to a certificate private
key or a password, so it should be protected accordingly.

CONFIGURING SERVICE PRINCIPALS

Host principals are created automatically when a host is joined to the IdM domain. The host
principal credential is downloaded and stored in /etc/krb5.keytab. Service principals are
created as required by an IdM administrator.

A service principal can be created through the IdM web UI by navigating to Identity → Services,
then clicking Add. Populate the required fields, then click Add to create the service.

106 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

Figure 3.1: Adding a service

Service principals can also be created from the command line using the ipa service-add
command.

After using either of the above methods, the keytab can be downloaded using the ipa-
getkeytab command:

[user@demo ~]$ ipa-getkeytab \

-s idm.lab.example.net \
-p HTTP/intranet.example.com \
-k /etc/httpd/conf/intranet.keytab

MANAGING HOST AND SERVICE PRINCIPALS

There may be times when it is desirable to disable access to a host or service temporarily. When
a host or service principal is disabled, the keytab attribute is set to False. Additionally, any
managed services are also disabled for hosts.

[user@demo ~]$ ipa service-show HTTP/intranet.example.com

Principal name: HTTP/intranet.example.com@EXAMPLE.COM
Principal alias: HTTP/intranet.example.com@EXAMPLE.COM
Keytab: True
Managed by: intranet.example.com
[user@demo ~]$ ipa service-disable HTTP/intranet.example.com
--------------------------------------------------------
Disabled service "HTTP/intranet.example.com@EXAMPLE.COM"
--------------------------------------------------------
[user@demo ~]$ ipa service-show HTTP/intranet.example.com
Principal name: HTTP/intranet.example.com@EXAMPLE.COM
Principal alias: HTTP/intranet.example.com@EXAMPLE.COM
Keytab: False
Managed by: intranet.example.com

To enable the service again, request a new keytab.

[user@demo ~]$ ipa-getkeytab \

-s idm.lab.example.net \
-p HTTP/intranet.example.com \
-k /etc/httpd/conf/intranet.keytab

RH362-RHEL-7.4-en-1-20181003 107
CHAPTER 3 | Authenticating Identities with Kerberos

Keytab successfully retrieved and stored in: /etc/httpd/conf/intranet.keytab

DELEGATING SERVICE MANAGEMENT

The ability to manage an IdM service can be delegated to the server hosting the service. Delegating
service management relieves the burden on IdM administrators, passing responsibility to the
service owner. By delegating to the host principal, any user with access to the server can retrieve
an updated keytab or request a certificate for the service.

The process to manage the service requires a user to authenticate using the host keytab file:

[user@demo ~]$ kinit -kt /etc/krb5.keytab host/$(hostname)

REFERENCES
Further information is available in the Managing Services chapter in the Linux Domain
Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

108 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

GUIDED EXERCISE

CONFIGURING HOSTS AND SERVICES

FOR KERBEROS
In this exercise, you will create, use, and validate host and service credentials.

OUTCOMES
You should be able to create and validate host and service credentials, as well as configure a
service to authenticate using Kerberos.

Log in to workstation as the student user and then open a terminal and execute the lab
auth-hosts setup command. This will ensure that the classroom is ready for this exercise.

[student@workstation ~]$ lab auth-hosts setup

1. From workstation, open a terminal session to utility as the student user, then
become root. Install the ipa-client package to obtain the necessary Kerberos and IPA tools
needed to configure utility as a Kerberos client system.

[student@workstation ~]$ ssh utility

[student@utility ~]$ sudo -i
[sudo] password for student: student
[root@utility ~]# yum install ipa-client
...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

2. From workstation, open a separate terminal session to idm as the student user, then
become root. Create a host principal for the utility.lab.example.net system.
2.1. Authenticate as the Kerberos admin user with the password RedHat123^.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

2.2. Use the ipa host-add command configure a host as a Kerberos client,
utility.lab.example.com, from the IdM server without using the LDAP back-
end as user information. Use the --ip-address option to define an IP address of
172.25.250.14 for the utility host.

[root@idm ~]# ipa host-add \

--ip-address=172.25.250.14 \

RH362-RHEL-7.4-en-1-20181003 109
CHAPTER 3 | Authenticating Identities with Kerberos

utility.lab.example.net
------------------------------------
Added host "utility.lab.example.net"
------------------------------------
Host name: utility.lab.example.net
Principal name: host/utility.lab.example.net@LAB.EXAMPLE.NET
Principal alias: host/utility.lab.example.net@LAB.EXAMPLE.NET
Password: False
Keytab: False
Managed by: utility.lab.example.net

2.3. Use the ipa host-add-managedby command and its --hosts option to add the
IdM server, idm.lab.example.net, to the list of systems that can manage the
utility.lab.example.net Kerberos client.

[root@idm ~]# ipa host-add-managedby --hosts=idm.lab.example.net \

utility.lab.example.net
Host name: utility.lab.example.net
Principal name: host/utility.lab.example.net@LAB.EXAMPLE.NET
Principal alias: host/utility.lab.example.net@LAB.EXAMPLE.NET
Managed by: utility.lab.example.net, idm.lab.example.net
-------------------------
Number of members added 1
-------------------------

3. Supply the utility system with the necessary files for Kerberos client configuration.
3.1. Copy the Kerberos configuration file, /etc/krb5.conf, to the Kerberos client
system, utility.lab.example.net.

[root@idm ~]# scp /etc/krb5.conf root@utility:/etc/krb5.conf

root@utility's password: redhat
krb5.conf 100% 925 553.5KB/s 00:00

3.2. Copy the IdM server's CA certificate file, /etc/ipa/ca.crt, to the Kerberos client
system, utility.lab.example.net.

[root@idm ~]# scp /etc/ipa/ca.crt root@utility:/etc/ipa/ca.crt

root@utility's password: redhat
ca.crt 100% 1325 717.2KB/s 00:00

4. Return to the terminal session on utility and complete its Kerberos client configuration.
4.1. With the Kerberos configuration file in place, authenticate as the Kerberos admin
user.

[root@utility ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

4.2. Use the cached Kerberos admin credential and issue the ipa-getkeytab
command to generate and retrieve the keytab for the utility.lab.example.net
host principal. Use the -s option to specify idm.lab.example.net as
the server to retrieve the keytab from. Use the -p option to specify host/
utility.lab.example.net as the principal for which the keytab is to be

110 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

generated and retrieved. Use the -k option to specify that the keytab is to be
exported to the /etc/krb5.keytab file.

[root@utility ~]# ipa-getkeytab \

-s idm.lab.example.net \
-p host/utility.lab.example.net \
-k /etc/krb5.keytab
Keytab successfully retrieved and stored in: /etc/krb5.keytab

4.3. Use klist to verify the installation of the keytab file and its contents.

[root@utility ~]# klist -k /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- ------------------------------------------------------------
1 host/utility.lab.example.net@LAB.EXAMPLE.NET
1 host/utility.lab.example.net@LAB.EXAMPLE.NET

4.4. Install the pam_krb5 package to allow integration of Kerberos authentication with
PAM.

[root@utility ~]# yum install pam_krb5

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

4.5. Use the authconfig command and its --enablekrb5 and --update options to
enable Kerberos authentication integration with PAM.

[root@utility ~]# authconfig --enablekrb5 --update

5. Use the useradd command to create the user admin on utility to test Kerberos user
authentication. The admin user is created locally, and not in the IdM server.

[root@utility ~]# useradd admin

6. From workstation, open a separate terminal session to the client system. The client
system is already configured as an IdM client. Use kinit to authenticate as the Kerberos
admin user.

[student@workstation ~]$ ssh client

[student@client ~]$ kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

7. Use klist to verify the credentials and tickets cached on client.

[student@client ~]$ klist

Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@LAB.EXAMPLE.NET

RH362-RHEL-7.4-en-1-20181003 111
CHAPTER 3 | Authenticating Identities with Kerberos

Valid starting Expires Service principal

03/13/2018 15:16:08 03/14/2018 15:16:05 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

8. Copy the SSHD configuration from client to utility, this enables GSSAPI
authentication.

[student@client ~]$ sudo scp /etc/ssh/sshd_config root@utility:/etc/ssh/

[sudo] password for student: student
root@utility's password: redhat
sshd_config 100% 4145 5.0MB/s 00:00

9. Switch to the terminal on utility then restart the sshd service.

[root@utility ~]# systemctl restart sshd

10. From client, make and then close, a connection to the SSHD service on
utility.lab.example.net. Notice how the connection used the Kerberos admin
credential cached on client, and therefore no password was required.

[student@client ~]$ ssh admin@utility.lab.example.net

The authenticity of host 'utility.lab.example.net (<no hostip for proxy command>)'
can't be established.
ECDSA key fingerprint is SHA256:lXmpBW0vCfgwrSGzb0qS9KzIlg2fTmp8k/lIsuCW21Q.
ECDSA key fingerprint is MD5:d2:2e:fe:6c:b9:ac:34:22:e9:1b:7d:d0:48:5c:67:42.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'utility.lab.example.net' (ECDSA) to the list of known
hosts.
[admin@utility ~]$ logout
Connection to utility.lab.example.net closed.
[student@client ~]$

11. Run klist again to display the credentials and tickets, which are now in the cache.
Note that there is now a cached ticket for the Kerberos service principal, host/
utility.lab.example.net@LAB.EXAMPLE.NET, used by the SSH service on utility.

[student@client ~]$ klist

Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

03/13/2018 15:16:15 03/14/2018 15:16:05 host/
utility.lab.example.net@LAB.EXAMPLE.NET
03/13/2018 15:16:08 03/14/2018 15:16:05 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

12. Switch to the utility terminal and examine the entries in the /var/log/secure
log file, which relate to the authentication of the admin user in the SSH session from
client to utility. Notice how the authorization that occurred on utility was for the
admin@LAB.EXAMPLE.NET Kerberos principal.

[root@utility ~]# tail /var/log/secure

...output omitted...

112 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

Mar 14 16:10:55 utility sshd[1671]: Authorized to admin, krb5 principal

admin@LAB.EXAMPLE.NET (ssh_gssapi_krb5_cmdok)
Mar 14 16:10:55 utility sshd[1671]: Accepted gssapi-with-mic for admin from
172.25.250.11 port 33460 ssh2
Mar 14 16:10:55 utility sshd[1671]: pam_unix(sshd:session): session opened for
user admin by (uid=0)
...output omitted...

Cleanup
From workstation, run the lab auth-hosts cleanup command to clean up this exercise.

[student@workstation ~]$ lab auth-hosts cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 113
CHAPTER 3 | Authenticating Identities with Kerberos

CONFIGURING REMOTE KERBEROS

AUTHENTICATION

OBJECTIVES
After completing this section, students should be able to:

• Configure Kerberos authenticate from outside the IdM domain

• Configure a web browser to use Kerberos authentication

INTRODUCING REMOTE KERBEROS AUTHENTICATION

At times there may be a requirement to access Kerberos-protected services from a machine
that is not a domain member. Common situations may include visiting contractors on projects,
meetings with business partners, visiting external auditors, and so on. This chapter describes how
to configure a machine to allow users to authenticate to IdM, and how to configure the GSSAPI
negotiate authentication method for a typical web browser.

CONFIGURING KERBEROS
To perform Kerberos authentication on a host that is not a member of an IdM domain, the krb5-
workstation package must be installed. The host also must have Kerberos configured. A quick
method is to copy the /etc/krb5.conf configuration file from an existing domain member, and
then edit it as required. However, if DNS is properly configured, the DNS server will automatically
pull the information. If the host is configured to authenticate to a different Kerberos domain, the
configuration file for the IdM domain can be given a different name in the [realms] section.

[user@demo ~]$ sudo yum install krb5-workstation

...output omitted...
[user@demo ~]$ sudo scp root@client:/etc/krb5.conf /etc/krb5.conf
krb5.conf 100% 925 565.2KB/s 00:00
[user@demo ~]$ sudo vi /etc/krb5.conf
[user@demo ~]$ kinit demo

CONFIGURING A WEB BROWSER FOR KERBEROS

AUTHENTICATION
With the krb5-workstation package installed and a Kerberos configuration file created, the Firefox
web browser can be configured to use the Simple and Protected GSSAPI Negotiation Mechanism
(SPNEGO) authentication method. SPNEGO allows a client and server to negotiate a common
GSSAPI authentication method, but is disabled by default in most browsers. If the Kerberos
configuration file is not using the default name and location of /etc/krb5.conf, export the
KRB5_CONFIG environment variable with the correct path and file name before launching the
Firefox web browser.

[user@demo ~]$ export KRB5_CONFIG=/etc/idm.conf

[user@demo ~]$ kinit demo
Password for demo@LAB.EXAMPLE.NET: demo12345
[user@demo ~]$ firefox

With the Firefox web browser open, navigate to about:config. Filter the settings by typing
negotiate. Set the network.negotiate-auth.trusted-uris option to the DNS name

114 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

of the Kerberos domain. The option admits a list of coma-separated URLs. Navigate to a web
site configured to use Kerberos authentication, such as the IdM web UI, then import the CA
certificate to permanently trust the site. The web browser should use your cached credentials to
transparently authenticate you to the web site.

Figure 3.2: Conﬁguring a web browser for Kerberos

To troubleshoot authentication failures, inspect the logs on the server side for applicable errors.

REFERENCES
Further information is available in the Configuring Firefox to Use Kerberos for Single
Sign-On chapter in the System-Level Authentication Guide at
https://access.redhat.com/articles/1586893

RH362-RHEL-7.4-en-1-20181003 115
CHAPTER 3 | Authenticating Identities with Kerberos

GUIDED EXERCISE

CONFIGURING REMOTE KERBEROS

AUTHENTICATION
In this exercise, you will perform Kerberos authentication commands and configure a web
browser for Kerberos authentication.

OUTCOMES
You should be able to authenticate from the command line and from a web browser on a non-
domain system.

Log in to workstation as the student user and then open a terminal and execute the lab
auth-remote setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab auth-remote setup

1. Log in to workstation as the student user. Using sudo, install the krb5-workstation
package.

[student@workstation ~]$ sudo yum install krb5-workstation

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.

#2) Think before you type.
#3) With great power comes great responsibility.

[sudo] password for student: student

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

2. Retrieve the Kerberos configuration file /etc/krb5.conf from the idm server, and
place it at /etc/krb5_ipa.conf on the workstation system. Use sudo, because the
placement of the file requires root privileges.

[student@workstation ~]$ sudo scp root@idm:/etc/krb5.conf /etc/krb5_ipa.conf

krb5.conf 100% 925 565.2KB/s 00:00

116 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

3. Configure workstation to use the newly downloaded IdM Kerberos configuration file by
defining /etc/krb5_ipa.conf as the value of the KRB5_CONFIG environment variable.

[student@workstation ~]$ export KRB5_CONFIG=/etc/krb5_ipa.conf

4. Use the kinit command to authenticate against the IdM server domain as the admin user
using the password RedHat123^. This command fails.

[student@workstation ~]$ kinit admin

kinit: Included profile directory could not be read while initializing Kerberos 5
library

5. The kinit error is due to the missing profile directory, /var/lib/sss/pubconf/

krb5.include.d/, which is referenced in the /etc/krb5_ipa.conf configuration file.
As root, comment out the following line in the configuration file to avoid the error.

includedir /var/lib/sss/pubconf/krb5.include.d/

6. Reattempt the previous Kerberos authentication. Use the kinit command to authenticate
against the IdM server domain as the admin user using the password RedHat123^. Use the
klist command to confirm a ticket for the admin principal is cached.

[student@workstation ~]$ kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^
[student@workstation ~]$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

03/11/2018 18:41:53 03/12/2018 18:41:51 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

7. Connect to the graphical desktop environment on workstation. Open a terminal session

and configure workstation to use the newly downloaded IdM Kerberos configuration
file by defining /etc/krb5_ipa.conf as the value of the KRB5_CONFIG environment
variable. Then launch a Firefox web browser session from the same terminal session.

[student@workstation ~]$ export KRB5_CONFIG=/etc/krb5_ipa.conf

[student@workstation ~]$ firefox

8. In the Firefox web browser, connect to https://idm.lab.example.net. You will

encounter a warning that the connection is not secure since the web site is using a self-
signed certificate. Click Advanced, Add Exception, and then Confirm Security Exception.

9. On the login page of the Red Hat Identity Management web UI, click the configured link
to configure the browser for Kerberos authentication. Then click manual configuration
page to proceed with manual configuration.

RH362-RHEL-7.4-en-1-20181003 117
CHAPTER 3 | Authenticating Identities with Kerberos

10. Using the instructions on the page, manually configure Firefox for Kerberos authentication.
10.1. Click the CA certificate link to import the IdM server's CA certificate.
10.2. Select the Trust this CA to identify websites and then click OK.
10.3. Open a separate tab in the Firefox browser. Enter about:config in the address bar
to display the current Firefox configurations. Click I accept the risk!.
10.4. Enter negotiate in the Search field.
10.5. Double-click network.negotiate-auth.trusted-uris. Enter
lab.example.net as the name of the domain to authenticate against, and then
click OK. Close the about:config tab in your Firefox browser.

11. In the Firefox web browser, reconnect to https://idm.lab.example.net. You are now
automatically logged in to Red Hat Identity Management web UI using the cached Kerberos
credential for the admin user.

Cleanup
From workstation, run the lab auth-remote cleanup command to clean up this exercise.

[student@workstation ~]$ lab auth-remote cleanup

This concludes the guided exercise.

118 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

MANAGING THE KERBEROS DOMAIN

OBJECTIVES
After completing this section, students should be able to:

• Explain principal key hashes.

• Set ticket use and expiration policies.

• Configure Kerberos principal parameters.

DESCRIBING THE PASSWORD AND KEY

RELATIONSHIP
The Kerberos protocol uses AES symmetric encryption. Each principal has a single key stored in
the KDC database, which is derived from their password. This means that when the password is
changed, a new key is generated. As a result, you can see the key hash change when the password
changes.

NOTE
Password and key hashes are not exposed through the IdM API, and can only be seen
using the Directory Manager user for the back-end LDAP directory. Viewing these
sensitive attributes is not required for regular IdM operations, and is only discussed
here to emphasize the relationship between passwords and keys.

KERBEROS TICKET POLICIES

When a user authenticates to the IdM domain, a ticket valid for some period of time is issued. This
time period is configurable at both a global or user-specific level. A user-specific ticket policy
overrides the global ticket policy.

Global and user-specific ticket policies are modified using the same command. If a user ID is
included, the command affects only that user. Otherwise, the modification is global.

[user@demo ~]$ ipa krbtpolicy-mod [userid] \

--maxrenew=seconds \
--maxlife=seconds

SETTING KERBEROS FLAGS ON SERVICE PRINCIPALS

There are several flags that can be set on service principals. The most common flags are related to
delegation.

OK_AS_DELEGATE
This flag is used when a service is trusted to have a client's TGT forwarded to it. This is used
when IdM has a trust relationship with Active Directory. Active Directory forwards the user's
TGT to the service if this flag is set.

OK_TO_AUTH_AS_DELEGATE
This flag is used when a service is trusted to authenticate as the client.

RH362-RHEL-7.4-en-1-20181003 119
CHAPTER 3 | Authenticating Identities with Kerberos

IMPORTANT
Setting this flag means that the service may run without higher privileges, and
impersonate clients to perform work on their behalf.

REQUIRES_PRE_AUTH
This flag, enabled by default, can be used to disable pre-authentication for a specific service.
This reduces load on the KDC but reduces the security of the service credential. The pre-
authentication feature was introduced to mitigate a weakness in the Kerberos protocol that
allowed an active attacker to perform offline password cracking.

Red Hat recommends to never disable pre-authentication.

To set one of these flags for a service principal, use the ipa service-mod command:

[user@demo ~]$ ipa service-mod \

HTTP/intranet.lab.example.net@LAB.EXAMPLE.NET \
--ok-as-delegate=1

To see the current flags set for a service principal, use the kadmin.local command:

[user@demo ~]$ kadmin.local

Authenticating as principal admin/admin@LAB.EXAMPLE.NET with password.
kadmin.local: getprinc HTTP/intranet.lab.example.net@LAB.EXAMPLE.NET
...output omitted...
Number of keys: 0
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH OK_AS_DELEGATE
Policy: [none]

REKEYING SERVICE OR HOST PRINCIPALS

User principals differ from host and service principals, in that password changes are common.
Host and service principal credentials have random passwords generated when they are created,
which are not subject to password expiry. A keytab is a sensitive item that must be protected,
because gaining access to a keytab allows anyone to impersonate the host or service. If a keytab
is suspected of being exposed, then a new key can be requested. Rekeying is the process of
requesting a new key from the KDC, which in turn increases the key version number (KVNO).

The following example requests a new key using the ipa-getkeytab command. The -p option
specifies the principal, -s specifies the server to retrieve the keytab from, and -k specifies where
to store it.

[user@demo ~]$ ipa-getkeytab \

-p HTTP/intranet.lab.example.net@LAB.EXAMPLE.NET \
-s idm.lab.example.net \
-k /etc/httpd/conf/intranet.keytab

To verify the new key version number, use the klist -kt keytab command:

[user@demo ~]$ klist -kt /etc/httpd/conf/intranet.keytab

Keytab name: FILE:/etc/httpd/conf/intranet.keytab
KVNO Timestamp Principal

120 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

---- ----------------- --------------------------------------------------------

2 16/03/18 09:35:13 HTTP/intranet.lab.example.net@LAB.EXAMPLE.NET
3 20/03/18 11:43:38 HTTP/intranet.lab.example.net@LAB.EXAMPLE.NET

NOTE
The previous key version is still in the keytab to allow existing sessions to expire
gracefully. New sessions will use the highest version key.

REFERENCES
Further information is available in the Managing Kerberos Flags and Principal Aliases
chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

Further information is available in the Managing the Kerberos Domain chapter in the
Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

RH362-RHEL-7.4-en-1-20181003 121
CHAPTER 3 | Authenticating Identities with Kerberos

GUIDED EXERCISE

MANAGING THE KERBEROS DOMAIN

In this exercise, you will perform Kerberos policy and principal maintenance.

OUTCOMES
You should be able to change the password on a user credential and rekey a Kerberos
principal.

Log in to workstation as the student user and then open a terminal and execute the lab
auth-manage setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab auth-manage setup

1. Log in to client.lab.example.net as the student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

2. Use kinit to authenticate as the helpdesk Kerberos user principal with the password
RedHat123^.

[root@client ~]# kinit helpdesk

Password for helpdesk@LAB.EXAMPLE.NET: RedHat123^

3. Use the ipa passwd command to reset the password for the idmuser01 user to redhat.

[root@client ~]# ipa passwd idmuser01

New Password: redhat
Enter New Password again to verify: redhat
------------------------------------------------
Changed password for "idmuser01@LAB.EXAMPLE.NET"
------------------------------------------------

4. On workstation, open a separate terminal to idm.lab.example.net, log in as

student then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

122 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

5. Run the date command with the --utc option to determine the current system time
expressed in UTC.

[root@idm ~]# date --utc

Sat Mar 24 05:42:26 UTC 2018

6. Use ldapsearch to query the directory for the idmuser01 user and restrict the
output to the following data fields: uid, userPassword, krbPrincipalKey, and
krbPasswordExpiration. Note that the value of krbPasswordExpiration ends with
Z, which indicates that the expiration time is expressed in UTC. If you compare this value
with the the current time displayed previously with the date command, you see that the
password for the idmuser01 user has already expired.

[root@idm ~]# ldapsearch -x -LLL \

-b "cn=accounts,dc=lab,dc=example,dc=net" \
-D "cn=Directory Manager" \
-w RedHat123^ \
"uid=idmuser01" uid userPassword krbPrincipalKey krbPasswordExpiration
dn: uid=idmuser01,cn=users,cn=accounts,dc=lab,dc=example,dc=net
uid: idmuser01
userPassword:: e1NTSEE1MTJ9MHQzS2RQM0I3Qi9sUFdtaCsxNUhBUHZpa0QrOEQrYlRkZkVMcFM
wbWZhR3VLN2ZDTUVON3NXS0hoRHBZOU1rcnFkbEcrb2JKVHFjTWhZSkZJQis4R0Q0K0N1cEpQajJn
krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEDowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBA3
XWMhUCUoTXtBLSVhXTR8oUkwR6ADAgESoUAEPiAA61VlQTP3Qjopeo8Xx3jEDVKfyGmt3YtxhXJ2z
ZI238THyjjsEE718GdbtZjEvzoUf/QfZNF0h4Q97YbEMFigGzAZoAMCAQShEgQQKCggXF46Tis4Nl
NQc0wuOKE5MDegAwIBEaEwBC4QANt7ZN9HiEoiJ5tmwcgGHszpFrRsQcx28zmsN5iSU9qDpA68ihz
9IPeqZc8l
krbPasswordExpiration: 20180518192150Z

7. Return to the terminal session on client. Use kinit to authenticate as the idmuser01
Kerberos user principal with the password redhat. When prompted to change the
password, set the new password to redhatnew.

[root@client ~]# kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: redhat
Password expired. You must change it now.
Enter new password: redhatnew
Enter it again: redhatnew

8. Return to the terminal session on idm. Repeat the same ldapsearch command executed
previously. Note that the value of the userPassword hash has changed due to the
password change. Note also that the value of the krbPrincipalKey hash has changed.
This is because the key is derived directly from the new user password.

[root@idm ~]# ldapsearch -x -LLL \

-b "cn=accounts,dc=lab,dc=example,dc=net" \
-D "cn=Directory Manager" \
-w RedHat123^ \
"uid=idmuser01" uid userPassword krbPrincipalKey krbPasswordExpiration
# extended LDIF
#
# LDAPv3

RH362-RHEL-7.4-en-1-20181003 123
CHAPTER 3 | Authenticating Identities with Kerberos

# base <cn=accounts,dc=lab,dc=example,dc=net> with scope subtree

# filter: uid=idmuser01
# requesting: uid userPassword krbPrincipalKey krbPasswordExpiration
#

# idmuser01, users, accounts, lab.example.net

dn: uid=idmuser01,cn=users,cn=accounts,dc=lab,dc=example,dc=net
uid: idmuser01
userPassword:: e1NTSEE1MTJ9T1lud25HTlZLZGRMQld3WHRuOXUxZWFKdmF3enhSYnB4Und4RmF
5TTRiMTZhS1BuYXNPR0tjZGlsSENlL0FURVdEUm5DR3hud0tsd3E1aGpGWE00Q1VielFQL2hiU3Ri
krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgECowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBBa
RSB6O1wyZ0dUfHRWeVdroUkwR6ADAgESoUAEPiAA0X6EfO68leGxs3C85x5GMwZtnrdDSN036kSrW
ARsecPVVZswuY87wcsjeoxOI+2x/l6FwHKhCEgwHSVjMFigGzAZoAMCAQShEgQQSVoib1YnQnprXj
U2Q01XQqE5MDegAwIBEaEwBC4QAAzlAI6gQydfdGloUTVXc9MM2pUiRa8VNHA6aGlcwdtBsfORYN4
gJ7tDZX9O
krbPasswordExpiration: 20180622060237Z

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

9. Return to the terminal session on client. Use kinit to authenticate as the admin
Kerberos user principal with the password RedHat123^. Then regenerate, retrieve,
and install the keytab for the client.lab.example.net host principal to the /etc/
krb5.keytab file. Display the contents of the file with klist. Note the new entries with
key version number (KVNO) 3.

[root@client ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^
[root@client ~]# ipa-getkeytab \
-p host/client.lab.example.net@LAB.EXAMPLE.NET \
-s idm.lab.example.net \
-k /etc/krb5.keytab
Keytab successfully retrieved and stored in: /etc/krb5.keytab
[root@client ~]# klist -kt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
1 20/03/18 11:59:51 host/client.lab.example.net@LAB.EXAMPLE.NET
1 20/03/18 11:59:51 host/client.lab.example.net@LAB.EXAMPLE.NET
3 24/03/18 17:08:01 host/client.lab.example.net@LAB.EXAMPLE.NET
3 24/03/18 17:08:01 host/client.lab.example.net@LAB.EXAMPLE.NET

Cleanup
From workstation, run the lab auth-manage cleanup command to clean up this exercise.

[student@workstation ~]$ lab auth-manage cleanup

This concludes the guided exercise.

124 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

LAB

AUTHENTICATING IDENTITIES WITH

KERBEROS

PERFORMANCE CHECKLIST
In this lab, you will configure a service principal and remote authentication, and then use
remote authentication to access the service principal.

OUTCOMES
You should be able to:

• Add the HTTP service on utility as a service principal in the LAB.EXAMPLE.NET

Kerberos realm.

• Configure the firewall on utility to give other systems HTTP access to the web server
already running on utility.

• Install the keytab for the HTTP/utility.lab.example.net service principal in /etc/

httpd/http.keytab on utility and configure Apache to authenticate using this
keytab.

• Configure the Apache web server on utility so that access to web content under
http://utility.lab.example.net/restricted is only authorized for the
idmuser01 Kerberos user.

• Configure the non-domain system, workstation, to use the provided /

etc/krb5_ipa.conf Kerberos configuration file to access http://
utility.lab.example.net/restricted as the idmuser01 Kerberos user.

Log in to workstation as the student user and then open a terminal and execute the lab
auth-review setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab auth-review setup

1. Create a service principal for the HTTP service, which will be configured on
utility.lab.example.net.
2. On utility, configure the firewall to provide other systems HTTP access to the web server,
which is already running.
3. On utility, install the keytab for the HTTP/utility.lab.example.com service
principal in the /etc/httpd/http.keytab for use by the Apache web server.
4. Configure the Apache web server on utility so that the resources under http://
utility.lab.example.net/restricted can only be accessed by the
idmuser01@LAB.EXAMPLE.NET Kerberos user principal. Place the configuration
parameters in the /etc/httpd/conf.d/restricted.conf configuration file.
5. On workstation, utilize the existing /etc/krb5_ipa.conf Kerberos configuration file to
authenticate as the idmuser01 Kerberos user.

RH362-RHEL-7.4-en-1-20181003 125
CHAPTER 3 | Authenticating Identities with Kerberos

6. The Firefox web browser on workstation has already been configured for Kerberos
authentication. Using Firefox, connect to http://utility.lab.example.net/
restricted with the cached user credential for the idmuser01 Kerberos user. If you are
successful, you should see the text, Restricted.

Evaluation
From workstation, run the lab auth-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab auth-review grade

Cleanup
From workstation, run the lab auth-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab auth-review cleanup

This concludes the lab.

126 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

SOLUTION

AUTHENTICATING IDENTITIES WITH

KERBEROS

PERFORMANCE CHECKLIST
In this lab, you will configure a service principal and remote authentication, and then use
remote authentication to access the service principal.

OUTCOMES
You should be able to:

• Add the HTTP service on utility as a service principal in the LAB.EXAMPLE.NET

Kerberos realm.

• Configure the firewall on utility to give other systems HTTP access to the web server
already running on utility.

• Install the keytab for the HTTP/utility.lab.example.net service principal in /etc/

httpd/http.keytab on utility and configure Apache to authenticate using this
keytab.

• Configure the Apache web server on utility so that access to web content under
http://utility.lab.example.net/restricted is only authorized for the
idmuser01 Kerberos user.

• Configure the non-domain system, workstation, to use the provided /

etc/krb5_ipa.conf Kerberos configuration file to access http://
utility.lab.example.net/restricted as the idmuser01 Kerberos user.

Log in to workstation as the student user and then open a terminal and execute the lab
auth-review setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab auth-review setup

1. Create a service principal for the HTTP service, which will be configured on
utility.lab.example.net.
1.1. Connect to idm.lab.example.net as the student user, become root then
authenticate as the admin Kerberos user principal.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.2. Use the ipa service-add command to add the service principal for the HTTP
service, which will be configured on utility.lab.example.net. Log out when
finished.

RH362-RHEL-7.4-en-1-20181003 127
CHAPTER 3 | Authenticating Identities with Kerberos

[root@idm ~]# ipa service-add HTTP/utility.lab.example.net

------------------------------------------------------------
Added service "HTTP/utility.lab.example.net@LAB.EXAMPLE.NET"
------------------------------------------------------------
Principal name: HTTP/utility.lab.example.net@LAB.EXAMPLE.NET
Principal alias: HTTP/utility.lab.example.net@LAB.EXAMPLE.NET
Managed by: utility.lab.example.net
[root@idm ~]# logout
[student@idm ~]$ logout
[student@workstation ~]$

2. On utility, configure the firewall to provide other systems HTTP access to the web server,
which is already running.
2.1. Connect to utility.lab.example.net as the student user, then become root.

[student@workstation ~]$ ssh utility

[student@utility ~]$ sudo -i
[sudo] password for student: student
[root@utility ~]#

2.2. Use firewall-cmd to allow access the http service on utility.

[root@utility ~]# firewall-cmd --add-service http

success
[root@utility ~]# firewall-cmd --add-service http --permanent
success

3. On utility, install the keytab for the HTTP/utility.lab.example.com service

principal in the /etc/httpd/http.keytab for use by the Apache web server.
3.1. Use kinit to authenticate as the admin Kerberos user.

[root@utility ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3.2. Use ipa-getkeytab to generate, retrieve, and install the keytab for the HTTP/
utility.lab.example.net service principal in the /etc/httpd/http.keytab
file on utility.lab.example.net.

[root@utility ~]# ipa-getkeytab \

-s idm.lab.example.net \
-p HTTP/utility.lab.example.net \
-k /etc/httpd/http.keytab
Keytab successfully retrieved and stored in: /etc/httpd/http.keytab

3.3. Change the ownership of the /etc/httpd/http.keytab on

utility.lab.example.net so that it can be accessed by the apache user, which
runs the httpd daemon.

[root@utility ~]# chown apache /etc/httpd/http.keytab

4. Configure the Apache web server on utility so that the resources under http://
utility.lab.example.net/restricted can only be accessed by the

128 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

idmuser01@LAB.EXAMPLE.NET Kerberos user principal. Place the configuration

parameters in the /etc/httpd/conf.d/restricted.conf configuration file.
4.1. Install the mod_auth_kerb package to integrate Kerberos authentication with Apache
web server.

[root@utility ~]# yum install mod_auth_kerb

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

4.2. Create the /etc/httpd/conf.d/restricted.conf configuration file with the

following contents:

<Location /restricted>
AuthType Kerberos
AuthName LAB.EXAMPLE.NET
KrbMethodNegotiate on
KrbMethodK5Passwd off
Require user idmuser01@LAB.EXAMPLE.NET
KrbServiceName HTTP
Krb5Keytab /etc/httpd/http.keytab
</Location>

4.3. Reload the httpd service, then log out.

[root@utility ~]# systemctl reload httpd

Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service
to /usr/lib/systemd/system/httpd.service.
[root@utility ~]# logout
[student@utility ~]$ logout
[student@workstation ~]$

5. On workstation, utilize the existing /etc/krb5_ipa.conf Kerberos configuration file to

authenticate as the idmuser01 Kerberos user.
5.1. Open a terminal session on workstation and set /etc/krb5_ipa.conf as the
value for the KRB5_CONFIG environmental variable.

[student@workstation ~]$ export KRB5_CONFIG=/etc/krb5_ipa.conf

5.2. Using kinit, authenticate as the idmuser01 Kerberos user with the password
redhatnew.

[student@workstation ~]$ kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

6. The Firefox web browser on workstation has already been configured for Kerberos
authentication. Using Firefox, connect to http://utility.lab.example.net/

RH362-RHEL-7.4-en-1-20181003 129
CHAPTER 3 | Authenticating Identities with Kerberos

restricted with the cached user credential for the idmuser01 Kerberos user. If you are
successful, you should see the text, Restricted.
6.1. Connect to the graphical desktop environment on workstation.
6.2. Open a terminal session in the graphical desktop environment and use klist to
confirm that the user credential for idmuser01@LAB.EXAMPLE.NET is still in the
cache.

[student@workstation ~]$ klist

Ticket cache: KEYRING:persistent:1000:krb_ccache_uqQJyDW
Default principal: idmuser01@LAB.EXAMPLE.NET

Valid starting Expires Service principal

03/23/2018 04:41:55 03/24/2018 04:41:53 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

6.3. In the same terminal session, configure workstation to use the /etc/
krb5_ipa.conf Kerberos configuration file as the value of the KRB5_CONFIG
environment variable. Then launch a Firefox web browser session from the same
terminal session.

[student@workstation ~]$ export KRB5_CONFIG=/etc/krb5_ipa.conf

[student@workstation ~]$ firefox

6.4. In the Firefox web browser, connect to http://utility.lab.example.net/

restricted. If you are successful, you should see the text Restricted.

Evaluation
From workstation, run the lab auth-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab auth-review grade

Cleanup
From workstation, run the lab auth-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab auth-review cleanup

This concludes the lab.

130 RH362-RHEL-7.4-en-1-20181003
CHAPTER 3 | Authenticating Identities with Kerberos

SUMMARY

In this chapter, you learned:

• Kerberos principals are created for users, hosts, and services. A principal has the format
primary[/instance]@REALM.

• Service principals are the best choice for services that may run on multiple machines. Hosts and
services keep their credentials in keytab files on the local system so that human intervention is
not required during startup.

• A system that is not part of the IdM domain can still be configured to authenticate to IdM
services by installing and configuring the krb5-workstation package.

• The IdM domain can control the lifetime and maximum renewal time for the Kerberos tickets
issued on a global or per-user basis.

RH362-RHEL-7.4-en-1-20181003 131
132 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4

MANAGING A PUBLIC KEY

INFRASTRUCTURE
GOAL Manage certificate authorities, certificates and
storing secrets.

OBJECTIVES • Discuss certificate architecture, structure, and

the generation and use of certificates.
• Describe common tasks for managing a
certificate life cycle and the securing of services
with certificates.
• Discuss secure methods for storing and
managing authentication secrets.
• Configure alternate forms of authentication for
specific high-security use cases.

SECTIONS • Describing the IdM Certificate Authority (and

Guided Exercise)
• Managing Certificates (and Guided Exercise)
• Managing Secrets (and Guided Exercise)
• Customizing Authentication (and Guided
Exercise)

LAB Managing a Public Key Infrastructure

RH362-RHEL-7.4-en-1-20181003 133
CHAPTER 4 | Managing a Public Key Infrastructure

DESCRIBING THE IDM CERTIFICATE

AUTHORITY

OBJECTIVES
After completing this section, students should be able to:

• Describe certificate service architecture.

• Configure a certificate authority.

CERTIFICATE AUTHORITIES AND CHAINING

In a Public Key Infrastructure, a Certificate Authority (CA) is either a third party trusted to verify
the identity of an entity (such as a user or a domain), or an externally-signed CA certificate signed
by a CA owned an operated by the same organization. The design of a Certificate Authority
architecture usually includes several layers of CAs, forming a chain. At the top of the chain is
the Root CA. The Root CA has signed its own certificate, and this certificate is the one that gets
embedded in web browsers as a trusted authority. Below the Root CA are Intermediate CAs. The
Intermediate CA certificates are signed by the Root CA, and may or may not issue certificates to
endpoints.

When a user navigates to a TLS-protected website, the server certificate is verified against the CA
that signed it, and the chain of CAs from the signing CA up to a trusted Root CA. If the chain does
not contain a trusted CA, the website is not trusted and a warning is displayed.

Figure 4.1: Certiﬁcate Authority chain

Certiﬁcates
Certificates can be used for many purposes, and may have varying amounts of trust. For example,
often the identity of a domain owner is only verified by sending an email to a common address,
such as hostmaster or webmaster. Anyone who can register or access one of these addresses can
potentially obtain a certificate for the domain.

There are several types of certificates, which vary based on their purpose, and the amount of
identity validation performed by the CA, such as Extended Validation (EV) certificates. Certificates
have other uses apart from validating web sites. For example, they identify a software publisher or
the sender of an email.

134 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

THE IDM CERTIFICATE AUTHORITY

During IdM server installation, you have the option to use an external CA or the integrated CA
provided as part of the product. The IdM integrated CA is a component from the upstream Dogtag
Certificate System project. The CA is a web app running in a Tomcat container, and the service is
pki-tomcatd@pki-tomcat.service.

The Key Recovery Authority (KRA) component from Dogtag is also used in IdM. It provides IdM
vault.

Certmonger
The certmonger service is included to automate the burden of certificate administration tasks.
Certmonger tracks certificates and can warn you when their expiry time approaches. It can even
attempt to renew your certificate, if told the private key location.

Certmonger is integrated with IdM, and is invoked when you use the getcert or ipa-getcert
command.

REFERENCES
Further information is available in the Managing Certificates and Certificate
Authorities chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

Dogtag Certiﬁcate System

http://www.dogtagpki.org/wiki/PKI_Main_Page

RH362-RHEL-7.4-en-1-20181003 135
CHAPTER 4 | Managing a Public Key Infrastructure

GUIDED EXERCISE

DESCRIBING THE IDM CERTIFICATE

AUTHORITY
In this exercise, you will examine the IdM Certificate Authority and certmonger.

OUTCOMES
You should be able to describe the IdM Certificate Authority.

Log in to workstation as the student user, then open a terminal and execute the lab pki-ca
setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-ca setup

1. Log in to the idm server as student using SSH, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

2. Check the status and logs for the certmonger service.

2.1. Check the status of the certmonger service to ensure that the service is enabled
and active (running).

[root@idm ~]# systemctl status certmonger.service

● certmonger.service - Certificate monitoring and PKI enrollment
Loaded: loaded (/usr/lib/systemd/system/certmonger.service; enabled; vendor
preset: disabled)
Active: active (running) since Tue 2018-03-20 11:44:29 AEDT; 2 weeks 6 days ago
Main PID: 4247 (certmonger)
CGroup: /system.slice/certmonger.service
└─4247 /usr/sbin/certmonger -S -p /var/run/certmonger.pid -n

Mar 20 11:45:29 idm.lab.example.net ipa-submit[5909]: GSSAPI client step 1

Mar 20 11:45:29 idm.lab.example.net ipa-submit[5909]: GSSAPI client step 1
...output omitted...

2.2. View the certmonger log messages.

[root@idm ~]# journalctl -l -u certmonger.service -r

Mar 20 11:45:37 idm.lab.example.net ipa-submit[6098]: GSSAPI client step 1
Mar 20 11:45:32 idm.lab.example.net renew_kdc_cert[6063]: restarting krb5kdc
Mar 20 11:45:29 idm.lab.example.net ipa-submit[5909]: GSSAPI client step 2
...output omitted...
Mar 20 11:45:28 idm.lab.example.net ipa-submit[5874]: GSSAPI client step 1

136 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

Mar 20 11:45:28 idm.lab.example.net ipa-submit[5874]: GSSAPI client step 1

Mar 20 11:45:24 idm.lab.example.net restart_httpd[5868]: certmonger restarted
httpd
Mar 20 11:45:13 idm.lab.example.net ipa-submit[5311]: GSSAPI client step 2
Mar 20 11:45:13 idm.lab.example.net ipa-submit[5311]: GSSAPI client step 1
Mar 20 11:45:13 idm.lab.example.net ipa-submit[5311]: GSSAPI client step 1
Mar 20 11:45:13 idm.lab.example.net ipa-submit[5311]: GSSAPI client step 1
Mar 20 11:45:13 idm.lab.example.net ipa-submit[5311]: GSSAPI client step 1

Notice that certmonger is restarting the krb5kdc service after renewing the KDC
certificate.

3. Check the status and log messages for the pki-tomcatd service.
3.1. Check the status of the pki-tomcatd@pki-tomcat.service service to ensure
that the service is enabled and active (running).

[root@idm ~]# systemctl status pki-tomcatd@pki-tomcat.service

● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; vendor
preset: disabled)
Active: active (running) since Mon 2018-04-09 10:11:38 AEST; 2h 36min ago
Process: 23998 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/
SUCCESS)
Process: 24046 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, status=0/
SUCCESS)
Main PID: 24193 (java)
CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-
tomcat.service
└─24193 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -DRESTEASY_LIB=/usr/
share/...

Apr 09 10:11:42 idm.lab.example.net server[24193]: PKIListener:

org.apache.catalina....]
Apr 09 10:11:42 idm.lab.example.net server[24193]: PKIListener: Subsystem CA is
running.
Apr 09 10:11:42 idm.lab.example.net server[24193]: PKIListener: Subsystem KRA is
run....
...output omitted...

3.2. View the pki-tomcatd log messages.

[root@idm ~]# journalctl -l -u pki-tomcatd@pki-tomcat.service

-- Logs begin at Tue 2018-03-20 11:32:10 AEDT, end at Mon 2018-04-09 12:52:15
AEST. --
Mar 20 11:43:40 idm.lab.example.net systemd[1]: Starting PKI Tomcat Server pki-
tomcat...
Mar 20 11:43:40 idm.lab.example.net pkidaemon[3535]: ----------------------
Mar 20 11:43:40 idm.lab.example.net pkidaemon[3535]: Enabled all subsystems
Mar 20 11:43:40 idm.lab.example.net pkidaemon[3535]: ----------------------
Mar 20 11:43:40 idm.lab.example.net pkidaemon[3535]: 'pki-tomcat' must still be
CONFIGURED!
Mar 20 11:43:40 idm.lab.example.net pkidaemon[3535]: (see /var/log/pki-tomcat-
install.log)
Mar 20 11:43:40 idm.lab.example.net systemd[1]: Started PKI Tomcat Server pki-
tomcat.

RH362-RHEL-7.4-en-1-20181003 137
CHAPTER 4 | Managing a Public Key Infrastructure

Mar 20 11:43:40 idm.lab.example.net server[3657]: Java virtual machine used: /usr/

lib/jvm/jre-
Mar 20 11:43:40 idm.lab.example.net server[3657]: classpath used: /usr/share/
tomcat/bin/bootst
Mar 20 11:43:40 idm.lab.example.net server[3657]: main class used:
org.apache.catalina.startup
Mar 20 11:43:40 idm.lab.example.net server[3657]: flags used: -DRESTEASY_LIB=/usr/
share/java/r
Mar 20 11:43:40 idm.lab.example.net server[3657]: options used: -Dcatalina.base=/
var/lib/pki/p
Mar 20 11:43:40 idm.lab.example.net server[3657]: arguments used: start
Mar 20 11:43:40 idm.lab.example.net server[3657]: WARNING: Problem with JAR file
[/usr/share/p

Scrolling to the right, you can see many CA properties being set, such as the ciphers
for SSL2, SSL3, and TLS.

Setting property 'enableOCSP' to 'false' did not find a matching property.

Setting property 'ocspResponderURL' to 'http://idm.lab.example.net:8080/ca/ocsp'
did not find a matching pro...
...output omitted...
Setting property 'ssl2Ciphers' to '-SSL2_RC4_128_WITH_MD5,-
SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_...
Setting property 'ssl3Ciphers' to '-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-
SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL...
Setting property 'tlsCiphers' to '-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA...
...output omitted...
Setting property 'xmlValidation' to 'false' did not find a matching property.
Setting property 'xmlNamespaceAware' to 'false' did not find a matching property.

3.3. Examine the /var/lib/pki/pki-tomcat/logs/ca/transactions log file.

Note that CRL updates occur regularly, every 4 hours.

[root@idm ~]# less /var/lib/pki/pki-tomcat/logs/ca/transactions

...output omitted...
0.CRLIssuingPoint-MasterCRL - [09/Apr/2018:13:00:00 AEST] [20] [1] CRL update
started. CRL ID: MasterCRL CRL Number: 95 Delta CRL Enabled: false CRL Cache
Enabled: true Cache Recovery Enabled: true Cache Cleared: false Cache: 0,0,0,0
0.CRLIssuingPoint-MasterCRL - [09/Apr/2018:13:00:00 AEST] [20] [1] CRL Update
completed. CRL ID: MasterCRL CRL Number: 95 last update time: 4/9/18 1:00 PM next
update time: 4/9/18 5:00 PM Number of entries in the CRL: 0 time: 13 CRL time:
13 delta CRL time: 0 (0,0,0,0,0,0,0,3,10,0,0,13,13)

3.4. The /var/lib/pki/pki-tomcat/logs/ca/debug log file tracks all actions

taken by the CA in detail, including connections to the IdM LDAP server, as well as
searches and updates to certificates.

[root@idm ~]# less /var/lib/pki/pki-tomcat/logs/ca/debug

...output omitted...
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: masterConn is connected: true
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: getConn: conn is connected true
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: getConn: mNumConns now 3
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: In findCertRecordsInListRawJumpto
with Jumpto 20180409162522Z

138 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

[09/Apr/2018:16:25:22][CertStatusUpdateTask]: In DBVirtualList filter attrs

startFrom sortKey pageSize filte
r: (certStatus=VALID) attrs: [objectclass, certRecordId, x509cert] pageSize -200
startFrom 20180409162522Z
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: returnConn: mNumConns now 4
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: returnConn: mNumConns now 5
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: DBVirtualList: searching for entry
20180409162522Z
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: DBVirtualList.getEntries()
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: DBVirtualList: entries: 1
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: DBVirtualList: top: 0
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: DBVirtualList: size: 14
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: transidValidCertificates: list size:
14
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: transitValidCertificates: ltSize 1
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: Record does not qualify,notAfter Mon
Mar 09 11:44:20 AEDT 2020
date Mon Apr 09 16:25:22 AEST 2018
[09/Apr/2018:16:25:22][CertStatusUpdateTask]: transitCertList EXPIRED

4. Log out from the idm server.

[root@idm ~]# logout

[student@idm ~]$ logout
[student@workstation ~]$

Cleanup
From workstation, run the lab pki-ca cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-ca cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 139
CHAPTER 4 | Managing a Public Key Infrastructure

MANAGING CERTIFICATES

OBJECTIVES
After completing this section, students should be able to:

• Manage certificate renewals and revocation lists.

• Install certificates to secure services.

CERTIFICATE LIFECYCLE
In an IdM environment, certificates can be managed in several ways depending on organization
requirements, or administrative staff preferences. You can manage certificates through
certmonger, or externally using certutil or openssl.

Certificates are only valid for a defined period, so creation and renewal are the most common
maintenance tasks. Revoking a certificate is not so common, but is an important task nonetheless.

Requesting a Certiﬁcate
The process to request a certificate varies depending on on the tools you decide to use. The
following list provides details for certmonger, certutil, and openssl.

Certmonger
Use the ipa-getcert request command. A Certificate Signing Request (CSR) is
automatically generated and sent to the Certificate Authority (CA), and then the resulting
certificate has its expiry date tracked by certmonger.

[root@demo ~]# ipa-getcert request -f /etc/httpd/intranet.pem \

-k /etc/httpd/intranet.key \
-K http/intranet.example.com \
-D intranet.example.com

Certutil
To generate a CSR, use the certutil -R command. The resulting file can be submitted to
your CA.

[root@demo ~]# certutil -R -d ~/certdb/ \

-a -g 4096 \
-n intranet \
-s "CN=intranet, O=EXAMPLE.COM" \
> ~/intranet.csr

Openssl
To generate a CSR, use the openssl req command. The resulting file can be submitted to
your CA.

[root@demo ~]# openssl req \

-out ~/intranet.csr -new \
-newkey rsa:2048 \

140 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

-nodes -sha256 \
-keyout ~/intranet.key

Renewing a Certiﬁcate
Renewing a certificate requires access to the existing private key.

Certmonger
Certmonger automatically renews certificates for the internal CA and for internal IdM services.
Use of the ipa-getcert request command is identical for a renewal and for a new request.
certmonger uses any existing keys found in the -k option path. If a key is not found, then one
is generated, which makes this a new request.

[root@demo ~]# ipa-getcert request -f /etc/httpd/intranet.pem \

-k /etc/httpd/intranet.key \
-K http/intranet.example.com \
-D intranet.example.com

Certutil
To renew a certificate, use the certutil -R -k command. The -k option specifies the
nickname of an existing key in the NSS database.

[root@demo ~]# certutil -R -d ~/certdb/ \

-a -g 4096 \
-k "NSS Certificate DB:intranet" \
-s "CN=intranet, O=EXAMPLE.COM" \
> ~/intranet.csr

OpenSSL
To renew a certificate, use the openssl req command, but reference an existing private key.

[root@demo ~]# openssl req \

-new \
-out ~/intranet.csr \
-key ~/intranet.key

Revoking a Certiﬁcate with an External CA

When using an external CA, the process for revoking a certificate varies. The CA usually needs a
certificate's serial number, and a reason for revoking the certificate.

Independent of the certificate revocation, the certificate can be removed from the IdM object. Use
the ipa object_type-remove-cert object_name command, where object_type is user,
host, or service. Provide the content of the certificate using the --certificate option.

[root@demo ~]# ipa user-remove-cert demouser \

--certificate="..."

RH362-RHEL-7.4-en-1-20181003 141
CHAPTER 4 | Managing a Public Key Infrastructure

NOTE
The content of the certificate must be the base64-encoded DER content. To
generate the file from a PEM file, run the following command:

[root@demo ~]# openssl x509 -inform PEM \

-outfrom DER < cert.pem | base64 > cert.b64

Revoking a Certiﬁcate with the Internal CA

When IdM is installed with the internal CA, the process to revoke a certificate is a single command.

Use the ipa cert-revoke command, provide the certificate serial number, and the revocation
reason. A table of revocation reasons can be found in the References.

[root@demo ~]# ipa cert-revoke 21 --revocation-reason=4

CERTIFICATES AND SERVICES

Certificates can be used to encrypt communication between clients and services that support SSL
or TLS. To obtain a certificate for a service, create a CSR using your preferred method, as shown in
the examples above.

When using the internal CA, simply add the -K option to the ipa-getcert request command to
specify the Kerberos principal to associate the certificate with.

For an external CA, associate the generated certificate with the service principal using the ipa
service-add-cert command.

Place the generated private key and certificate in a location that the service can access, ensure
that permissions are restricted to protect the key from exposure.

REFERENCES
Further information is available in the Managing Certificates for Users, Hosts, and
Services chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

Dogtag Certiﬁcate System

http://www.dogtagpki.org/wiki/PKI_Main_Page

142 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

GUIDED EXERCISE

MANAGING CERTIFICATES
In this exercise, you will:

• Create user and server certificates.

• Renew and revoke certificates.

• Configure secure services using certificates.

OUTCOMES
You should be able to manage the life cycle of user and service certificates.

Log in to workstation as the student user, then open a terminal and execute the lab pki-
certs setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-certs setup

1. Create a certificate for the idmuser01 user, using the certutil command.
1.1. Log in to the idm server as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Authenticate to IdM as the admin user.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.3. Create a directory to hold the NSS certificate database.

[root@idm ~]# mkdir ~/idmuser01-cert

1.4. Create an NSS certificate database using the certutil command.

[root@idm ~]# certutil -N -d ~/idmuser01-cert/

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password: RedHat123^

Re-enter password: RedHat123^

1.5. Create a certificate signing request (CSR) using the certutil command. The CN
attribute in the subject must match the user name for the user certificates.

RH362-RHEL-7.4-en-1-20181003 143
CHAPTER 4 | Managing a Public Key Infrastructure

[root@idm ~]# certutil -R -d ~/idmuser01-cert/ \

-a -g 4096 \
-n idmuser01 \
-s "CN=idmuser01, O=LAB.EXAMPLE.NET" \
> ~/idmuser01.csr
Enter Password or Pin for "NSS Certificate DB":RedHat123^

A random seed must be generated that will be used in the

creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter

is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!

Continue typing until the progress meter is full:

|************************************************************|

Finished. Press enter to continue:[Enter]

Generating key. This may take a few moments...

1.6. Submit the CSR to the IdM-integrated CA using the ipa cert-request
command. The default certificate profile used is for network services, so specify
IECUserRoles for the profile-id option. You must use the certificate-out
option to save a copy of the certificate. The certificate must be added to the NSS
database as well or the key will be orphaned and renewal will be impossible.

NOTE
If your organization is not using the integrated CA, now is when you would submit
the CSR to your alternate CA.

[root@idm ~]# ipa cert-request \

--profile-id IECUserRoles \
--certificate-out ~/idmuser01.pem \
--principal idmuser01@LAB.EXAMPLE.NET ~/idmuser01.csr
Issuing CA: ipa
Certificate: MIIFFzCCA/+
...output omitted...
Subject: CN=idmuser01,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Not Before: Wed Apr 11 02:11:35 2018 UTC
Not After: Sat Apr 11 02:11:35 2020 UTC
Serial number: 15
Serial number (hex): 0xF

1.7. Use the ipa user-show command to verify that the idmuser01 user now has a
certificate configured.

[root@idm ~]# ipa user-show idmuser01

144 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

User login: idmuser01

First name: idmuser01
Last name: idm
Home directory: /home/idmuser01
Login shell: /bin/sh
Principal name: idmuser01@LAB.EXAMPLE.NET
Principal alias: idmuser01@LAB.EXAMPLE.NET
Email address: idmuser01@example.net
UID: 123800003
GID: 123800003
Certificate: MIIFFzCCA/+
...output omitted...
Account disabled: False
Password: True
Member of groups: idmgroup03, ipausers
Kerberos keys available: True

1.8. Add the certificate to the NSS database. Use the -n option to set the nickname, it
must match the previous nickname to link the certificate with the key. The -t option
sets the trust level. See the man page for details. The -i option specifies the input
certificate file.

[root@idm ~]# certutil -A -d idmuser01-cert/ \

-n idmuser01 \
-t "P,," \
-i ~/idmuser01.pem

1.9. Verify that the key in the NSS database does not show (orphan) as its nickname.

[root@idm ~]# certutil -K -d idmuser01-cert/

certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and
Certificate Services"
Enter Password or Pin for "NSS Certificate DB": RedHat123^
< 0> rsa 5ad14d41463b87a095b1896cf0068ccc467df395 NSS Certificate
DB:idmuser01

1.10. Log out from the idm server.

[root@idm ~]# logout

[student@idm ~]$ logout
[student@workstation ~]$

2. Configure the vsftpd service to use TLS encryption. The packages for this exercise are
already installed.
2.1. Log in to the client server as the student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

2.2. Authenticate to IdM as the admin user.

[root@client ~]# kinit admin

RH362-RHEL-7.4-en-1-20181003 145
CHAPTER 4 | Managing a Public Key Infrastructure

Password for admin@LAB.EXAMPLE.NET: RedHat123^

2.3. Add a service principal for vsftpd.

[root@client ~]# ipa service-add ftp/client.lab.example.net

----------------------------------------------------------
Added service "ftp/client.lab.example.net@LAB.EXAMPLE.NET"
----------------------------------------------------------
Principal name: ftp/client.lab.example.net@LAB.EXAMPLE.NET
Principal alias: ftp/client.lab.example.net@LAB.EXAMPLE.NET
Managed by: client.lab.example.net

2.4. Create a directory to store certificates and keys in.

[root@client ~]# mkdir /etc/vsftpd/certs

2.5. Certmonger is not permitted to create certificates in arbitrary locations. Configure an

SELinux file context for the directory created in the previous step.

[root@client ~]# semanage fcontext -a -t cert_t "/etc/vsftpd/certs(/.*)?"

2.6. Set the SELinux context for the /etc/vsftpd/certs directory.

[root@client ~]# restorecon -R -v /etc/vsftpd/certs

restorecon reset /etc/vsftpd/certs context unconfined_u:object_r:etc_t:s0-
>unconfined_u:object_r:cert_t:s0

2.7. Create a certificate request for the ftp/client.lab.example.net principal

using the ipa-getcert request command. Use the -f and -k options to specify
where to store the certificate and key.

[root@client ~]# ipa-getcert request -f /etc/vsftpd/certs/cert.pem \

-k /etc/vsftpd/certs/cert.key \
-K ftp/client.lab.example.net \
-D client.lab.example.net
New signing request "20180406093054" added.

2.8. Verify that certmonger is monitoring the certificate request using the getcert
list command, and the request ID from the previous step.

[root@client ~]# getcert list -i 20180406093054

Request ID '20180406093054':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/vsftpd/certs/cert.key'
certificate: type=FILE,location='/etc/vsftpd/certs/cert.pem'
CA: IPA
issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
subject: CN=client.lab.example.net,O=LAB.EXAMPLE.NET
expires: 2020-04-06 09:30:55 UTC
dns: client.lab.example.net
principal name: ftp/client.lab.example.net@LAB.EXAMPLE.NET
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:

146 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

post-save command:
track: yes
auto-renew: yes

2.9. Edit the /etc/vsftpd/vsftpd.conf file and add the following directives.

ssl_enable=YES
rsa_cert_file=/etc/vsftpd/certs/cert.pem
rsa_private_key_file=/etc/vsftpd/certs/cert.key

2.10. Enable and start the vsftpd service.

[root@client ~]# systemctl enable vsftpd --now

Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service
to /usr/lib/systemd/system/vsftpd.service.

2.11. Connect to the vsftpd service using the ftp command. The standard FTP client
does not support encryption.

[root@client ~]# ftp client.lab.example.net

Connected to client.lab.example.net (172.25.250.11).
220 (vsFTPd 3.0.2)
Name (client.lab.example.net:root): student
530 Non-anonymous sessions must use encryption.
Login failed.
421 Service not available, remote server has closed connection
ftp>

2.12. Now connect to the vsftpd service using lftp command. This client supports
encryption of both command and data channels using TLS. Use the debug option
to show the commands, most significantly the AUTH command, being sent in the
background.

[root@client ~]# lftp -e debug client.lab.example.net

lftp client.lab.example.net:~> user student
Password: student
lftp student@client.lab.example.net:~> ls
---- Connecting to client.lab.example.net (172.25.250.11) port 21
<--- 220 (vsFTPd 3.0.2)
---> FEAT
<--- 211-Features:
<--- AUTH TLS
<--- EPRT
<--- EPSV
<--- MDTM
<--- PASV
<--- PBSZ
<--- PROT
<--- REST STREAM
<--- SIZE
<--- TVFS
<--- UTF8
<--- 211 End
---> AUTH TLS
<--- 234 Proceed with negotiation.

RH362-RHEL-7.4-en-1-20181003 147
CHAPTER 4 | Managing a Public Key Infrastructure

---> OPTS UTF8 ON

Certificate: O=LAB.EXAMPLE.NET,CN=client.lab.example.net
Issued by: O=LAB.EXAMPLE.NET,CN=Certificate Authority
Trusted
<--- 200 Always in UTF8 mode.
---> USER student
<--- 331 Please specify the password.
---> PASS XXXX
<--- 230 Login successful.
---> PWD
<--- 257 "/home/student"
---> PBSZ 0
<--- 200 PBSZ set to 0.
---> PROT P
<--- 200 PROT now Private.
---> PASV
<--- 227 Entering Passive Mode (172,25,250,11,25,17).
---- Connecting data socket to (172.25.250.11) port 6417
---- Data connection established
---> LIST
<--- 150 Here comes the directory listing.
Certificate: O=LAB.EXAMPLE.NET,CN=client.lab.example.net
Issued by: O=LAB.EXAMPLE.NET,CN=Certificate Authority
Trusted
-rw-rw-r-- 1 1000 1000 65536 Apr 09 00:44 database.kbdx
---- Got EOF on data connection
---- Closing data socket
<--- 226 Directory send OK.
lftp student@client.lab.example.net:~> bye
---> QUIT
---- Closing control socket

2.13. Log out from the client server.

[root@client ~]# logout

[student@client ~]$ logout
[student@workstation ~]$

3. Renew the certificate for the idmuser01 user, using the certutil command.
3.1. Log in to the idm server as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

3.2. Determine whether your Kerberos ticket is still valid. Reauthenticate as required.

[root@idm ~]# klist

Ticket cache: KEYRING:persistent:0:0
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

11/04/18 11:48:00 12/04/18 10:49:11 HTTP/idm.lab.example.net@LAB.EXAMPLE.NET

148 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

11/04/18 10:49:13 12/04/18 10:49:11 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

3.3. Determine the key nickname used in the previous CSR with the certutil command.

[root@idm ~]# certutil -K -d ~/idmuser01-cert/

3.4. Create a new certificate signing request (CSR) using the certutil command. Use
the -k option to provide the key nickname. Providing an existing key makes this
request a renewal rather than a new request with the same details. All attributes
must be identical to the previous request.

[root@idm ~]# certutil -R -d ~/idmuser01-cert/ \

-a -g 4096 \
-k "NSS Certificate DB:idmuser01" \
-s "CN=idmuser01, O=LAB.EXAMPLE.NET" \
> ~/idmuser01.csr
Enter Password or Pin for "NSS Certificate DB":RedHat123^

Note that there is no key generated, because in this example you are using an
existing one.
3.5. Submit the CSR to the IdM-integrated CA using the ipa cert-request
command. The default certificate profile used is for network services, so specify
IECUserRoles for the profile-id option. Remember to use the certificate-
out option to save a copy of the certificate.

[root@idm ~]# ipa cert-request \

--profile-id IECUserRoles \
--certificate-out ~/idmuser01.pem \
--principal idmuser01@LAB.EXAMPLE.NET ~/idmuser01.csr
Issuing CA: ipa
Certificate: MIIFFzCCA/+
...output omitted...
Subject: CN=idmuser01,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Not Before: Wed Apr 11 13:29:51 2018 UTC
Not After: Sat Apr 11 13:29:51 2020 UTC
Serial number: 16
Serial number (hex): 0x10

3.6. Add the certificate to the NSS database.

[root@idm ~]# certutil -A -d idmuser01-cert/ \

-n idmuser01 \
-t "P,," \
-i ~/idmuser01.pem

RH362-RHEL-7.4-en-1-20181003 149
CHAPTER 4 | Managing a Public Key Infrastructure

4. Revoke the original certificate for the idmuser01 user. Use Superseded as the revocation
reason.
4.1. Find all certificates owned by idmuser01.

[root@idm ~]# ipa cert-find --users idmuser01

----------------------
2 certificates matched
----------------------
Issuing CA: ipa
Subject: CN=idmuser01,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Not Before: Wed Apr 11 02:11:35 2018 UTC
Not After: Sat Apr 11 02:11:35 2020 UTC
Serial number: 15
Serial number (hex): 0xF
Status: VALID
Revoked: False

Issuing CA: ipa

Subject: CN=idmuser01,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Not Before: Wed Apr 11 13:29:51 2018 UTC
Not After: Sat Apr 11 13:29:51 2020 UTC
Serial number: 16
Serial number (hex): 0x10
Status: VALID
Revoked: False
----------------------------
Number of entries returned 2
----------------------------

4.2. Revoke the certificate with the earliest serial number (15). Use revocation code 4,
meaning the certificate has been superseded.

[root@idm ~]# ipa cert-revoke 15 --revocation-reason 4

Revoked: True

4.3. Find all certificates owned by idmuser01 once again. Note the status of the
certificate with serial number 15.

[root@idm ~]# ipa cert-find --users idmuser01

Issuing CA: ipa

150 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

4.4. Log out from the idm server.

[root@idm ~]# logout

[student@idm ~]$ logout
[student@workstation ~]$

Cleanup
From workstation, run the lab pki-certs cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-certs cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 151
CHAPTER 4 | Managing a Public Key Infrastructure

MANAGING SECRETS

OBJECTIVES
After completing this section, students should be able to:

• Describe the types and methods of vaults.

• Store and use authentication secrets.

SECRETS
A secret is any piece of sensitive information that should only be available to one or more people.
Information used for authenticating to a system is a common type of secret, and may include PINs,
certificates, passwords, and keys. Storage of secrets can be problematic and has given rise to items
such as smart cards, however not all systems can support authentication using a smart card.

IDM VAULTS
IdM provides a software-based solution for the storage of secrets called vaults. A vault can contain
only one secret, however several vaults can reside in a vault container. Vault containers are created
and deleted dynamically. Vaults can contain private secrets for users, secrets for services, or
secrets to be shared among several users. IdM supports these use cases with several types of
vaults, providing options to specify whether the vault is owned by a user or service, and whether it
is shared. You should specify the vault type and other attributes when you create a vault, or it may
not meet your needs.

NOTE
If an IdM administrator creates a user's first vault, the vault container and the vault
will be owned by that admin and the user will be unable to access it. If this occurs,
resolve this error by either deleting all vaults, then deleting the vault container using
the ipa vaultcontainer-del command, or adding the user as an owner then
removing the admin from the vault container and vault.

IdM Vault Permissions

Owner
There must be at least one owner of a vault. Owners can be users or services, and can modify
vault properties.

Member
A vault member can access a vault created by an owner.

Administrator
A vault administrator can manage all vaults.

IdM Vault Types

Standard
The standard vault type allows the owner and members to retrieve secrets without providing a
password.

152 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

Symmetric
The symmetric vault type protects secrets with a symmetric key. The key must be provided
when archiving and retrieving secrets.

Asymmetric
The asymmetric vault type protects secrets with an asymmetric key-pair. Secrets are archived
using the public key and retrieved with the private.

VAULT OPERATIONS
Common vault operations include adding a vault, storing (archiving) a secret, and retrieving a
secret. The following examples show the creation and use of a personal standard vault:

[root@demo ~]# kinit demo

Password for demo@LAB.EXAMPLE.NET:RedHat123^
[root@demo ~]# ipa vault-add payroll-vault \
--type standard
---------------------------
Added vault "payroll-vault"
---------------------------
Vault name: payroll-vault
Type: standard
Owner users: demo
Vault user: demo
[root@demo ~]# ipa vault-archive payroll-vault \
--in ~/staff-salaries-2018.xlsx
----------------------------------------
Archived data into vault "payroll-vault"
----------------------------------------

[root@lappy ~]# kinit demo

Password for demo@LAB.EXAMPLE.NET:RedHat123^
[root@lappy ~]# ipa vault-retrieve payroll-vault \
--out ~/staff-salaries-2018.xlsx
-----------------------------------------
Retrieved data from vault "payroll-vault"
-----------------------------------------

NOTE
By default, a vault only allows 1 MB uploads.

REFERENCES
Further information is available in the Storing Authentication Secrets with Vaults
chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

RH362-RHEL-7.4-en-1-20181003 153
CHAPTER 4 | Managing a Public Key Infrastructure

GUIDED EXERCISE

MANAGING SECRETS
In this exercise, you will:

• Configure a secrets vault.

• Store and retrieve secrets.

OUTCOMES
You should be able to manage standard vaults and secrets.

Log in to workstation as the student user, then open a terminal and execute the lab pki-
secrets setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-secrets setup

1. Install the Key Recovery Authority (KRA) on the idm server.

1.1. Log in to the idm server as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Install the KRA using the ipa-kra-install command

[root@idm ~]# ipa-kra-install

Directory Manager password: RedHat123^

===================================================================
This program will setup Dogtag KRA for the IPA Server.

Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes

[1/9]: configuring KRA instance
[2/9]: create KRA agent
[3/9]: restarting KRA
[4/9]: configure certmonger for renewals
[5/9]: configure certificate renewals
[6/9]: configure HTTP to proxy connections
[7/9]: add vault container
[8/9]: apply LDAP updates
[9/9]: enabling KRA instance
Done configuring KRA server (pki-tomcatd).
Restarting the directory server
The ipa-kra-install command was successful

154 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

1.3. Log out from the idm server.

[root@idm ~]# logout

[student@idm ~]$ logout
[student@workstation ~]$

2. As student on client, create a standard vault, and then store a secret in it.
2.1. Log in to client as the student user.

[student@workstation ~]$ ssh student@client

[student@client ~]$

2.2. View the size and modification time of the /home/student/database.kdbx file.

[student@client ~]$ ls -l ~/database.kdbx

-rw-rw-r--. 1 student student 65536 Apr 12 14:44 /home/student/database.kdbx

2.3. Authenticate to IdM as the idmuser01 user.

[student@client ~]$ kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

2.4. Create a standard vault using the ipa vault-add command.

[student@client ~]$ ipa vault-add keepassx-vault --type standard

----------------------------
Added vault "keepassx-vault"
----------------------------
Vault name: keepassx-vault
Type: standard
Owner users: idmuser01
Vault user: idmuser01

2.5. Store the /home/student/database.kdbx file using the ipa vault-archive

command.

[student@client ~]$ ipa vault-archive keepassx-vault --in ~/database.kdbx

-----------------------------------------
Archived data into vault "keepassx-vault"
-----------------------------------------

2.6. Log out of the client server.

[student@client ~]$ logout

[student@workstation ~]$

3. As student on idm, retrieve a secret stored in keepassx-vault.

3.1. Log in to idm as the student user.

[student@workstation ~]$ ssh student@idm

RH362-RHEL-7.4-en-1-20181003 155
CHAPTER 4 | Managing a Public Key Infrastructure

[student@idm ~]$

3.2. Authenticate to IdM as the idmuser01 user.

[student@idm ~]$ kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

3.3. Retrieve a secret stored in keepassx-vault.

[student@idm ~]$ ipa vault-retrieve keepassx-vault --out ~/database.kdbx

------------------------------------------
Retrieved data from vault "keepassx-vault"
------------------------------------------

3.4. View the details for the /home/student/database.kdbx file. Note that the size
matches the original file but the modification time is now. Only the content of the file
is stored in the vault, not the file itself.

[student@idm ~]$ ls -l ~/database.kdbx

-rw-rw-r--. 1 student student 65536 Apr 12 22:53 /home/student/database.kdbx

3.5. Log out of the idm server.

[student@idm ~]$ logout

[student@workstation ~]$

Cleanup
From workstation, run the lab pki-secrets cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-secrets cleanup

This concludes the guided exercise.

156 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

CUSTOMIZING AUTHENTICATION

OBJECTIVES
After completing this section, students should be able to:

• Configure certificates for alternate authentication methods.

• Configure remote authentication.

SMART CARD AUTHENTICATION

Smart cards have been in use for several decades, providing reliable storage for personal data,
including identification data, such as certificates and keys. IdM supports the use of smart cards as
a Kerberos v5 preauthentication mechanism. This means that a user can log on to a machine that is
an IdM domain member with a smart card, and automatically receive a Kerberos ticket.

Preauthentication
The original Kerberos specification had a flaw that allowed attackers to perform offline dictionary
attacks against a user credential. The flaw was mitigated by adding the preauthentication
phase. This requires the user to provide the KDC with some data encrypted with their private key,
before the Authentication Service (AS) grants a session key for the TGS.

There are many preauthentication (PA) mechanisms, a common method is to simply encrypt the
timestamp of the current time. Kerberos includes support for Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT), which is specified in RFC4556. This mechanism allows a user
to authenticate to Kerberos by passing their public key and a signature in the PA data field during
the AS request.

IDM CONFIGURATION FOR PKINIT SMART CARD

AUTHENTICATION
When the first IdM server is installed, if your base OS is Red Hat Enterprise Linux 7.4 or later then
your domain level is set to 1 and PKINIT is enabled by default. If the base OS of your IdM servers
was upgraded to Red Hat Enterprise Linux 7.4 or later, PKINIT can be configured once the domain
level is increased to 1.

To test whether PKINIT is enabled on your IdM servers, execute the ipa pkinit-status
command.

[root@idm ~]# ipa pkinit-status

----------------
1 server matched
----------------
Server name: idm.lab.example.net
PKINIT status: enabled
----------------------------
Number of entries returned 1
----------------------------

Conﬁgure a Client for Smart Card Authentication

To configure a client machine to use smart card authentication, perform the following steps:

RH362-RHEL-7.4-en-1-20181003 157
CHAPTER 4 | Managing a Public Key Infrastructure

[root@idm ~]# ipa-advise \

config-client-for-smart-card-auth > ~/client_pkinit.sh
[root@idm ~]# chmod u+x ~/client_pkinit.sh

Copy the script to the client machine. Execute it with an argument of the path to the certificate for
the CA that signed the smart card certificates. Ensure that the krb5-pkinit package is installed.

[root@client ~]# ~/client_pkinit.sh /etc/pki/Demo-CA.crt

...output omitted...
[root@client ~]# rpm -q krb5-pkinit

Conﬁgure the IdM Web UI for Smart Card Authentication

To enable smart card authentication for the IdM web UI, perform the following steps:

[root@idm ~]# ipa-advise \

config-server-for-smart-card-auth > ~/server_pkinit.sh
[root@idm ~]# chmod u+x ~/server_pkinit.sh

Execute the script on all IdM servers. Ensure that the sssd-dbus package is installed.

[root@idm ~]# ~/server_pkinit.sh

...output omitted...
[root@idm ~]# rpm -q sssd-dbus

BROWSER CONFIGURATION FOR PKINIT

Web browsers do not have smart card authentication enabled by default. To enable this feature,
you must add a Security Device. The following steps describe the process:

1. Launch Firefox.

2. Navigate to Edit → Preferences → Advanced → Certificates → Security Devices.

3. Click Load, then enter OpenSC for Module Name, and /usr/lib64/opensc-pkcs11.so for
Module filename.

4. Click OK, and then OK.

AUTHENTICATING TO THE IDM WEB UI WITH A SMART

CARD
Authenticating to the IdM web UI with a smart card is now enabled.

1. Navigate to the IdM management URL.

2. Click Login Using Certificate.

3. Enter the PIN to unlock your smart card.

4. Select the appropriate certificate, then click OK.

158 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

REFERENCES
Further information is available in the PKINIT Smart-card Authentication in Identity
Management chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

RFC4556: PKINIT
https://www.ietf.org/rfc/rfc4556.txt

RH362-RHEL-7.4-en-1-20181003 159
CHAPTER 4 | Managing a Public Key Infrastructure

GUIDED EXERCISE

CUSTOMIZING AUTHENTICATION
In this exercise, you will:

• Configure certificates for alternate authentication methods.

• Configure remote authentication.

OUTCOMES
You should be able to configure IdM for smart card authentication, and authenticate to IdM
using a certificate.

NOTE
This exercise uses the idmuser01 certificate created in the Managing
Certificates guided exercise. If you have not completed it, please do so before
continuing.

This exercise imports certificates directly into the browser to perform certificate-
based authentication because the classroom environment does not support smart
cards for all modalities.

Log in to workstation as the student user, then open a terminal and execute the lab pki-
auth setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-auth setup

1. Configure IdM to support smart card authentication. This is required to enable certificate-
based authentication, even without smart cards.
1.1. Log in to the idm server as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Authenticate to IdM as the admin user.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.3. Run the ipa-advise config-server-for-smart-card-auth command to

generate a configuration script. Make the script executable, and then run it.

[root@idm ~]# ipa-advise \

config-server-for-smart-card-auth > ~/server_smart_card_script.sh
trying https://idm.lab.example.net/ipa/json

160 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

[root@idm ~]# chmod u+x ~/server_smart_card_script.sh

[root@idm ~]# ~/server_smart_card_script.sh
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@LAB.EXAMPLE.NET

Valid starting Expires Service principal

16/04/18 12:58:04 17/04/18 12:55:55 HTTP/idm.lab.example.net@LAB.EXAMPLE.NET
16/04/18 12:55:55 17/04/18 12:55:55 krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET
--------------------
1 IPA server matched
--------------------
Server name: idm.lab.example.net
Min domain level: 0
Max domain level: 1
----------------------------
Number of entries returned 1
----------------------------
Loaded plugins: langpacks, search-disabled-repos
Package 32:bind-utils-9.9.4-50.el7.x86_64 already installed and latest version
Nothing to do
The ipa-pkinit-manage command was successful
PKINIT already enabled

2. Export the idmuser01 certificate to PKCS12 format, then log out.

2.1. Use the pk12util command to export the idmuser01 certificate from the /root/
idmuser01-cert NSS database.

[root@idm ~]# pk12util \

-d ~/idmuser01-cert/ \
-o ~/idmuser01.p12 \
-n idmuser01
Enter Password or Pin for "NSS Certificate DB": RedHat123^
Enter password for PKCS12 file: RedHat123^
Re-enter password: RedHat123^
pk12util: PKCS12 EXPORT SUCCESSFUL

2.2. Authenticate to IdM as the idmuser01 user to ensure the password has not expired.

[root@idm ~]# kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

2.3. Log out of the idm server.

[root@idm ~]# logout

[student@idm ~]$ logout
[student@workstation ~]$

3. Copy the /root/idmuser01.p12 file to workstation.

[student@workstation ~]$ scp root@idm:idmuser01.p12 ./

RH362-RHEL-7.4-en-1-20181003 161
CHAPTER 4 | Managing a Public Key Infrastructure

4. On workstation, import the user and CA certificates into Firefox.

4.1. Import the idmuser01 certificate.
Open Firefox, then navigate to Preferences → Advanced → Certificates. Click
View Certificates, Your Certificates, then Import. Navigate to the student home
directory, then open the idmuser01.p12 file. Enter RedHat123^ to unlock the file,
then click OK and OK.
4.2. Save the IdM CA certificate locally.
Navigate to https://idm.lab.example.net. Click Advanced on the Insecure
Connection warning page, then Add Exception. Click View, Details, select Certificate
Authority, then click Export. Save the CA certificate in the default location, then click
Close, and Cancel.
4.3. Import the IdM CA certificate.

NOTE
Only perform this step if you have not previously imported the CA certificate for IdM.
If you have reset the IdM VM, then it is possible a previously imported CA certificate
will no longer be valid. To resolve this issue, remove the currently trusted certificate,
then reimport.

Open Firefox, then navigate to Preferences → Advanced → Certificates. Click View

Certificates, and then click Authorities, and then Import. Navigate to the student
home directory. Open the CertificateAuthority.crt file. Trust the certificate
to identify websites, then click OK and OK.

5. Log in to the IdM web UI using a certificate.

5.1. Navigate to https://idm.lab.example.net or refresh the tab if it's already
open.
5.2. On the IdM web UI login page, click Login Using Certificate. The idmuser01
certificate should already be selected. Uncheck Remember this decision, then click
OK.
You are now logged in, looking at the details page for idmuser01.

Cleanup
From workstation, run the lab pki-auth cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-auth cleanup

This concludes the guided exercise.

162 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

LAB

MANAGING A PUBLIC KEY

INFRASTRUCTURE

PERFORMANCE CHECKLIST
In this lab, you will install a mariadb server, configure it use SSL, and then restrict access to
a specific user and require a certificate to authenticate. You will create a vault to hold the /
root/idmuser01.p12 file.

OUTCOMES
You should be able to secure a service using an SSL certificate.

NOTE
This lab uses the /root/idmuser01.p12 file from the Customizing Authentication
exercise, if you have not completed it, please do so before proceeding.

Log in to workstation as the student user, then open a terminal and execute the lab pki-
review setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-review setup

1. As the idmuser01 user, create a standard vault named db-vault, then store the /root/
idmuser01.p12 file from the idm server in it.
2. On client, install the mariadb-server package, then enable the mariadb service.
3. As admin, create the mysql/client.lab.example.net service principal.
4. Create the /etc/mariadb-certs directory, then request a certificate for the mariadb
service. Save the certificate as /etc/mariadb-certs/cert.pem and the key as /etc/
mariadb-certs/key.pem. Copy the CA certificate from the idm server to the /etc/
mariadb-certs directory, ensure the mysql user can read all certificates and keys.
5. Enable SSL for the mariadb server. The options you need are ssl-ca, ssl-cert, and ssl-
key. You can also set the ssl_cipher option to TLSv1.2.
6. Run the mysql_secure_installation command. Set the root password to RedHat123^.
Accept the defaults for all other questions.
7. Log in to the mariadb database using the mysql command. Verify that the SSL variables
were successfully enabled.
8. Create a database named top_secret. Grant all privileges on this database to
'idmuser01'@'localhost' but require that the user have a certificate issued by /
O=LAB.EXAMPLE.NET/CN=Certificate Authority, and a certificate subject of /
O=LAB.EXAMPLE.NET/CN=idmuser01. This ensures that only the idmuser01 user can
access this database, and that they must have a valid certificate issued by the IdM CA. Log
out of mariadb when finished.

RH362-RHEL-7.4-en-1-20181003 163
CHAPTER 4 | Managing a Public Key Infrastructure

9. As idmuser01, retrieve the idmuser01.p12 file stored in db-vault in the root user's
home directory. Extract the key and certificate from idmuser01.p12 using the openssl
pkcs12 command. Name the certificate idmuser01.pem and the key idmuser01.key.
10. Connect to mariadb as the idmuser01 user. Use the ssl_cert, and ssl_key options.
Use the command create table top_secret.documents (level INT NOT NULL,
name VARCHAR(128) NOT NULL); to test database permissions. Use the describe
command to show the table details. Log out of mariadb when finished.

Evaluation
From workstation, run the lab pki-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab pki-review grade

Cleanup
From workstation, run the lab pki-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-review cleanup

This concludes the lab.

164 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

SOLUTION

MANAGING A PUBLIC KEY

INFRASTRUCTURE

OUTCOMES
You should be able to secure a service using an SSL certificate.

NOTE
This lab uses the /root/idmuser01.p12 file from the Customizing Authentication
exercise, if you have not completed it, please do so before proceeding.

Log in to workstation as the student user, then open a terminal and execute the lab pki-
review setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab pki-review setup

1. As the idmuser01 user, create a standard vault named db-vault, then store the /root/
idmuser01.p12 file from the idm server in it.
1.1. Log on to the idm server as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Authenticate to IdM as the idmuser01 user.

[root@idm ~]# kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

1.3. Create a standard vault named db-vault.

[root@idm ~]# ipa vault-add db-vault --type standard

----------------------
Added vault "db-vault"
----------------------
Vault name: db-vault
Type: standard
Owner users: idmuser01
Vault user: idmuser01

RH362-RHEL-7.4-en-1-20181003 165
CHAPTER 4 | Managing a Public Key Infrastructure

1.4. Store the /root/idmuser01.p12 file in db-vault, then log out.

[root@idm ~]# ipa vault-archive db-vault --in ~/idmuser01.p12

-----------------------------------
Archived data into vault "db-vault"
-----------------------------------
[root@idm ~]# logout
[student@idm ~]$ logout
[student@workstation ~]$

2. On client, install the mariadb-server package, then enable the mariadb service.
2.1. Log in to client as the student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

2.2. Install the mariadb-server package.

[root@client ~]# yum install mariadb-server

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Installed:
mariadb-server.x86_64 1:5.5.56-2.el7
...output omitted...

Complete!

2.3. Enable the mariadb service.

[root@client ~]# systemctl enable mariadb

Created symlink from /etc/systemd/system/multi-user.target.wants/mariadb.service
to /usr/lib/systemd/system/mariadb.service.

3. As admin, create the mysql/client.lab.example.net service principal.

3.1. Authenticate to IdM as the admin user.

[root@client ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3.2. Create the mysql/client.lab.example.net service principal.

[root@client ~]# ipa service-add mysql/client.lab.example.net

------------------------------------------------------------
Added service "mysql/client.lab.example.net@LAB.EXAMPLE.NET"
------------------------------------------------------------
Principal name: mysql/client.lab.example.net@LAB.EXAMPLE.NET
Principal alias: mysql/client.lab.example.net@LAB.EXAMPLE.NET
Managed by: client.lab.example.net

166 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

4. Create the /etc/mariadb-certs directory, then request a certificate for the mariadb
service. Save the certificate as /etc/mariadb-certs/cert.pem and the key as /etc/
mariadb-certs/key.pem. Copy the CA certificate from the idm server to the /etc/
mariadb-certs directory, ensure the mysql user can read all certificates and keys.
4.1. Create the /etc/mariadb-certs directory.

[root@client ~]# mkdir /etc/mariadb-certs

4.2. Set the correct SELinux context so that certmonger can write to the directory.

[root@client ~]# semanage fcontext -a -t cert_t "/etc/mariadb-certs(/.*)?"

[root@client ~]# restorecon -R -v /etc/mariadb-certs
restorecon reset /etc/mariadb-certs context unconfined_u:object_r:etc_t:s0-
>unconfined_u:object_r:cert_t:s0

4.3. Request a certificate using the ipa-getcert command.

[root@client ~]# ipa-getcert request -f /etc/mariadb-certs/cert.pem \

-k /etc/mariadb-certs/key.pem \
-K mysql/client.lab.example.net \
-D client.lab.example.net
New signing request "20180417042118" added.

4.4. Ensure that the request has been processed and the certificate is being monitored by
certmonger.

[root@client ~]# getcert list -i 20180417042118

Number of certificates and requests being tracked: 1.
Request ID '20180417042118':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/mariadb-certs/key.pem'
certificate: type=FILE,location='/etc/mariadb-certs/cert.pem'
CA: IPA
issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
subject: CN=client.lab.example.net,O=LAB.EXAMPLE.NET
expires: 2020-04-17 04:21:18 UTC
dns: client.lab.example.net
principal name: mysql/client.lab.example.net@LAB.EXAMPLE.NET
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

4.5. Copy the IdM CA certificate from the idm server to the /etc/mariadb-certs
directory.

[root@client ~]# scp root@idm:/etc/ipa/ca.crt /etc/mariadb-certs/

Password: redhat

RH362-RHEL-7.4-en-1-20181003 167
CHAPTER 4 | Managing a Public Key Infrastructure

ca.crt 100% 1325 1.7MB/s 00:00

4.6. Ensure that the mysql user can read all certificates and keys.

[root@client ~]# chown mysql: /etc/mariadb-certs/*

5. Enable SSL for the mariadb server. The options you need are ssl-ca, ssl-cert, and ssl-
key. You can also set the ssl_cipher option to TLSv1.2.
Edit the /etc/my.cnf.d/server.cnf file. Add the following options below the
[mariadb] section header.

ssl-ca=/etc/mariadb-certs/ca.crt
ssl-cert=/etc/mariadb-certs/cert.pem
ssl-key=/etc/mariadb-certs/key.pem
ssl_cipher=TLSv1.2

6. Run the mysql_secure_installation command. Set the root password to RedHat123^.

Accept the defaults for all other questions.
6.1. Start the mariadb service.

[root@client ~]# systemctl start mariadb

6.2. Run the mysql_secure_installation command.

[root@client ~]# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):[Enter]

OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n][Enter]

New password: RedHat123^
Re-enter new password: RedHat123^
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone

to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

168 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

Remove anonymous users? [Y/n][Enter]

... Success!

Normally, root should only be allowed to connect from 'localhost'. This

ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n][Enter]

... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n][Enter]

- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n][Enter]

... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

7. Log in to the mariadb database using the mysql command. Verify that the SSL variables
were successfully enabled.
7.1. Connect to mariadb as the root user.

[root@client ~]# mysql -uroot -p

Enter password:RedHat123^
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 5.5.56-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

7.2. Display the values for all SSL variables.

MariaDB [(none)]> show variables like '%ssl%';

+---------------+-----------------------------+
| Variable_name | Value |
+---------------+-----------------------------+
| have_openssl | YES |

RH362-RHEL-7.4-en-1-20181003 169
CHAPTER 4 | Managing a Public Key Infrastructure

MariaDB [(none)]>

8. Create a database named top_secret. Grant all privileges on this database to

'idmuser01'@'localhost' but require that the user have a certificate issued by /
O=LAB.EXAMPLE.NET/CN=Certificate Authority, and a certificate subject of /
O=LAB.EXAMPLE.NET/CN=idmuser01. This ensures that only the idmuser01 user can
access this database, and that they must have a valid certificate issued by the IdM CA. Log
out of mariadb when finished.
8.1. Create the top_secret database.

MariaDB [(none)]> create database top_secret;

Query OK, 1 row affected (0.00 sec)

8.2. Grant permissions to the idmuser01 user.

MariaDB [(none)]> GRANT ALL PRIVILEGES ON top_secret.* \

TO 'idmuser01'@'localhost' \
REQUIRE ISSUER '/O=LAB.EXAMPLE.NET/CN=Certificate Authority' \
AND SUBJECT '/O=LAB.EXAMPLE.NET/CN=idmuser01';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> quit

Bye
[root@client ~]#

[root@client ~]# kinit idmuser01

Password for idmuser01@LAB.EXAMPLE.NET: RedHat123^

9.2. Retrieve the idmuser01.p12 file.

[root@client ~]# ipa vault-retrieve db-vault --out ~/idmuser01.p12

------------------------------------
Retrieved data from vault "db-vault"
------------------------------------

9.3. Extract the key and certificate.

[root@client ~]# openssl pkcs12 \

-in ~/idmuser01.p12 -nocerts -nodes -out ~/idmuser01.key
Enter Import Password:RedHat123^

170 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

MAC verified OK
[root@client ~]# openssl pkcs12 \
-in ~/idmuser01.p12 -clcerts -nokeys -out ~/idmuser01.pem
Enter Import Password:RedHat123^
MAC verified OK

10. Connect to mariadb as the idmuser01 user. Use the ssl_cert, and ssl_key options.
Use the command create table top_secret.documents (level INT NOT NULL,
name VARCHAR(128) NOT NULL); to test database permissions. Use the describe
command to show the table details. Log out of mariadb when finished.
10.1. Log in to mariadb.

[root@client ~]# mysql -uidmuser01 \

--ssl_cert ~/idmuser01.pem \
--ssl_key ~/idmuser01.key
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 17
Server version: 5.5.56-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

10.2. Create a table in the top_secret database.

MariaDB [(none)]> create table top_secret.documents ( \

level INT NOT NULL, \
name VARCHAR(128) NOT NULL);
Query OK, 0 rows affected (0.01 sec)

10.3. Use the describe command to show the table details.

MariaDB [(none)]> describe top_secret.documents;

MariaDB [(none)]> quit

Bye
[root@client ~]#

Evaluation
From workstation, run the lab pki-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab pki-review grade

RH362-RHEL-7.4-en-1-20181003 171
CHAPTER 4 | Managing a Public Key Infrastructure

Cleanup
From workstation, run the lab pki-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab pki-review cleanup

This concludes the lab.

172 RH362-RHEL-7.4-en-1-20181003
CHAPTER 4 | Managing a Public Key Infrastructure

SUMMARY

In this chapter, you learned:

• Certificate issuing organizations use multiple layers of Certificate Authorities. This is known as
a chain. When validating certificates, applications must follow the chain of CAs until they reach a
trusted Root CA.

• Certmonger simplifies the management of certificates for users, hosts, and services. Common
certificate management tasks include requesting, renewing, and revoking certificates.

• IdM provides a vault service that allows users and services to store and retrieve secrets such as
private keys.

• IdM supports PKINIT for smart cards, which allows users to authenticate to a domain member
system with a smart card, and automatically receive a Kerberos ticket. The IdM web UI also
supports authentication using smart cards.

RH362-RHEL-7.4-en-1-20181003 173
174 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5

INTEGRATING IDM WITH

ACTIVE DIRECTORY
GOAL Creating a trust relationship with Active Directory

OBJECTIVES • Configure RHEL systems to authenticate

directly with an Active Directory server.
• Configure an IdM Server to share Active
Directory accounts by configuring a trust
relationship.
• Configure IdM functionality to use an Active
Directory environment effectively.

SECTIONS • Accessing Active Directory Using Direct

Integration (and Guided Exercise)
• Accessing Active Directory Using a Trust
Relationship (and Guided Exercise)
• Managing Active Directory Integration (and
Guided Exercise)

LAB Integrating IdM with Active Directory

RH362-RHEL-7.4-en-1-20181003 175
CHAPTER 5 | Integrating IdM with Active Directory

ACCESSING ACTIVE DIRECTORY USING

DIRECT INTEGRATION

OBJECTIVES
After completing this section, students should be able to:

• Describe SSSD service functions.

• Describe Winbind and realmd services.

• Configure a Samba share.

You can integrate Linux clients with an Active Directory domain in two different ways: direct
integration or indirect integration. With indirect integration, clients connect to an IdM domain
that handles requests to Active Directory on their behalf. With direct integration, clients connect
directly to an Active Directory domain. While direct integration uses native LDAP and Kerberos
PAM and NSS modules, indirect integration uses cross-realm Kerberos trust with Active Directory,
or object synchronization between an IdM domain and Active Directory.

SELECTING A DIRECT INTEGRATION METHOD

You have three choices for direct integration between a Linux system and Active Directory.
For each integration, you need two components: one to interact with the central identity and
authentication source, and one to detect the available domains, and to configure the first
component.

The following list describes the three choices:

• System Security Services Daemon (SSSD): allows access to a remote identity and
authentication resource by using a framework that provides caching and offline support to the
clients. SSSD has many options to suit the environments. It provides PAM and NSS integration,
and a database to store local users. Red Hat recommends using SSSD to connect a Linux system
with identity servers such as Active Directory, IdM, or any generic LDAP or Kerberos server.

Direct integration with SSSD only works within a single Active Directory forest by default. For
multi-forest setup, configure manual domain enumeration as described in the knowledge base
on Joining SSSD to domains in different forests listed in the references section.

SSSD can be used for both direct and indirect integration, and allows to switch from one
integration approach to another without inducing significant migration costs. Use the realmd
service to configure SSSD or Winbind for direct integration of a Linux system with Active
Directory. The service automatically discovers information about accessible domains and realms,
and does not require advanced configuration to join a domain or a realm.

Identity management can be maintained in local configuration files for small deployments. Large
deployments usually require centralized management of identity-related policies, such as host-
based access control, sudo policies, or SELinux user mappings. You can accomplish that by
using systems management such as Red Hat Satellite.

• Native LDAP and Kerberos PAM and NSS modules: uses the nss_ldap, pam_ldap, and
pam_krb5 modules. These modules are loaded into every application process, and they directly
affect the execution environment.

These modules do not offer caching, offline support, or sufficient protection of credentials. Red
Hat discourages the use of these modules due to their limited functionality.

176 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

• Samba Winbind: emulates a Windows client on a Linux system in order to be able to

communicate with Active Directory servers. Recent versions of SSSD can be used as a
replacement for Winbind.

USING SSSD FOR DIRECT INTEGRATION

The System Security Services Daemon (SSSD) is a system service that provides access to remote
directories and authentication mechanisms. The daemon connects a local system (a client) to an
external back-end (a domain). The client is able to access and authenticate against remote services
through an SSSD provider.

Active Directory supports the usage of SSSD to use LDAP as an identity provider along with
Kerberos for authentication. Note that Linux and Microsoft Windows systems use different
identifiers for users and groups: Linux uses POSIX-compliant user identifiers (UIDs) and group
identifiers (GIDs), whereas Microsoft Windows systems use security identifiers (SIDs). SSSD
provides integration capabilities assigning Active Directory users a UID and a GID, as presented in
the following section.

Integration is broken down into six steps, independent from each other, described in detail in the
following sections.

• Integration prerequisites
• Generating new UIDs and GIDs for Active Directory users
• Using POSIX Attributes Defined in Active Directory
• Renewing Kerberos Host Keytab
• Enabling Dynamic DNS Updates
• Managing Access for Group Policy Objects

Integration Prerequisites
The following list describes the prerequisites for using Active Directory as an identity provider for
SSSD.

• Ensure that name resolution is valid for SRV records. Use the dig command to ensure that
resolution works. For example, to verify SRV record for the ad.lab.example.net domain, run
the following command:

[user@demo ~]$ dig -t SRV _ldap._tcp.ad.lab.example.net

Run the following command to verify Active Directory records:

[user@demo ~]$ dig -t SRV _ldap._tcp.dc._msdcs.ad.lab.example.net

• Ensure that the time on the SSSD server and Active Directory server is synchronized. This
ensures that Kerberos is able to work properly.

• Open the required ports on the Linux system and all Active Directory domain controllers for
ingress and egress traffic between the Linux system and the Active Directory domain controller.
The following table lists the ports required for direct integration of Linux systems into Active
Directory using SSSD.

SERVICE PORT PROTOCOL

DNS 53 TCP and UDP

LDAP 389 TCP and UDP

RH362-RHEL-7.4-en-1-20181003 177
CHAPTER 5 | Integrating IdM with Active Directory

SERVICE PORT PROTOCOL

LDAP Global Catalog 3268 TCP

Kerberos 88 and 464 TCP and UDP

(optional) NTP 123 UDP

• If needed, configure user home directories and shells. The pam_oddjob_mkhomedir.so library
automatically creates home directories when users first log in to Linux systems. By default,
SSSD retrieves the format of the home directory from the Active Directory identity provider.
However, you can customize the directory format on Linux clients by updating the [domain]
section of the /etc/sssd/sssd.conf configuration file and choosing one of the two following
options:

• fallback_homedir, which sets a fallback home directory format, used only if a home
directory is not defined in Active Directory.

• override_homedir, which sets a home directory template that overrides the home
directory defined in Active Directory.

Restart the SSSD service after updating the configuration file.

Generating New UIDs and GIDs for Active Directory Users

SSSD can use the SID of an Active Directory user to algorithmically generate POSIX IDs in a
process called ID mapping. ID mapping creates a map between SIDs in Active Directory and IDs
on Linux.

• When SSSD detects a new Active Directory domain, it assigns a range of available IDs to the new
domain, and each Active Directory domain ends up having the same identifier on every SSSD
client.

• When an Active Directory user logs in to an SSSD client machine for the first time, SSSD creates
an entry for the user in the SSSD cache, including a user identifier based on the user's SID and
the ID range for the managed domain.

• Because the IDs for Active Directory users are generated in a consistent way from the same
SID, the user has the same UID and GID when logging in to any Red Hat Enterprise Linux
system.

NOTE
For more information on the mapping of IDs, consult the section on Configuring an
AD Domain with ID Mapping as a Provider for SSSD in the Windows Integration Guide
listed in the references section.

Mapping remains consistent when all client systems use SSSD to map SIDs to Linux IDs.
However, if some clients use different software, you can either ensure that the same mapping
algorithm is used on all clients or use explicit POSIX attributes.

Using POSIX Attributes Deﬁned in Active Directory

Active Directory can create and store POSIX attributes, such as uidNumber, gidNumber,
unixHomeDirectory, or loginShell.

178 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

IMPORTANT
Previously, there was a popular extension to Active Directory, called Identity
Management for UNIX. This extension is now deprecated. See the article Identity
Management for UNIX listed in the references section for information.

WARNING
When using the ID mapping method, SSSD creates new UIDs and GIDs, which
overrides the values defined in Active Directory. To keep the values defined by
Active Directory, you must disable ID mapping in SSSD.

The following procedure lists the steps for using POSIX attributes in Active Directory.

1. In the Active Directory domain section of the /etc/sssd/sssd.conf configuration file, add
the ldap_id_mapping = false entry.

2. Remove the SSSD caches if you previously requested any users with the default ID mapping
configuration:

[root@demo ~]$ rm -f /var/lib/sss/db/*

Renewing Kerberos Host Keytab

SSSD automatically renews the Kerberos host Keytab file in an Active Directory environment if the
adcli package is installed. The daemon checks daily if the machine account password is older than
the configured value and renews it if necessary. The default renewal interval is 30 days. To update
the interval, update ad_maximum_machine_account_password_age in the Active Directory
domain section of the /etc/sssd/sssd.conf configuration file, and restart the sssd.service.

To disable the automatic Kerberos host Keytab renewal, give the

ad_maximum_machine_account_password_age option a value of 0.

Enabling Dynamic DNS Updates

Active Directory allows the clients to refresh their DNS records automatically, and actively
maintains DNS records to ensure that they stay current. Updates include the expiry (called aging)
and removal of inactive records (called scavenging). However, scavenging is not enabled by default
in Active Directory.

SSSD allows Linux systems to act like Windows clients by refreshing their DNS records, which also
prevents their records from being marked inactive and being removed from the DNS database.
When dynamic DNS updates are enabled, a client's DNS record is refreshed as follows:

• When the identity provider comes online

• When Linux systems reboot

• At a specified interval (this is an optional configuration; by default, the Active Directory provider
updates the DNS record every 24 hours)

You can configure these settings to match the interval of the DHCP leases. In this case, the Linux
client is renewed after the lease is renewed.

You only need to enable secure connections for the DNS updates to work because DNS updates are
sent to the Active Directory server using Kerberos along the Generic Security Services API (GSSAPI)

RH362-RHEL-7.4-en-1-20181003 179
CHAPTER 5 | Integrating IdM with Active Directory

for DNS (using GSS-TSIG). Set the dynamic DNS configuration for each domain, as shown in the
following example. For more information on the available options, see the sssd-ad(5) man page,
as listed in the references section.

[domain/ad.lab.example.net]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad

ldap_schema = ad
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

Managing Access for Group Policy Objects

Group Policy is a Microsoft Windows feature that enables administrators to centrally manage
policies for users and computers in Active Directory environments. A group policy object (GPO) is a
collection of policy settings that are stored on a domain controller (DC) and can be applied to policy
targets, such as computers and users. GPO policy settings related to Windows logon rights (that is,
controlling how security principals are allowed to access to the computer) are commonly used to
manage computer-based access control in Active Directory environments.

When you configure SSSD to apply GPO access control, SSSD retrieves the GPOs applicable to host
systems and Active Directory users. Based on the GPO configuration retrieved, SSSD determines
whether a user is allowed to log in to a particular host. This enables the administrator to define
login policies, honored by both Linux and Windows clients, centrally on the Active Directory domain
controller.

You can further limit the scope of GPO access control by using Security filtering. You can use
filtering to limit the scope to specific users, groups, or hosts by listing them in the security filter.

However, SSSD only supports users and groups in the security filter and ignores host entries. To
manage host entries, you need to:

• Create a new Organizational Unit (OU) in the Active Directory domain.

• Move or create a new object using that OU in the Active Directory domain.
• Link the GPO to the organizational unit (OU).

The following table lists GPO access control options that SSSD retrieves:

GPO OPTION MATCHING OPTION IN SSSD.CONF

Allow or deny log on locally ad_gpo_map_interactive

Allow or deny log on through remote ad_gpo_map_remote_interactive

desktop services

Allow or deny access to a system from the ad_gpo_map_network

network

Allow or deny log on as a batch job ad_gpo_map_batch

Allow or deny log on as a service ad_gpo_map_service

180 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

GPO-based access control can be configured in the /etc/sssd/sssd.conf configuration file.

The ad_gpo_access_control option specifies the running mode for the GPO-based access
control runs. You can set the running mode to permissive, enforcing, or disabled.

Permissive mode
Permissive mode is the default setting. Give the ad_gpo_access_control option a value of
permissive for the GPO-based access control to be evaluated but not enforced. A syslog
message is recorded every time access is be denied.

Enforcing mode
Give the ad_gpo_access_control option a value of enforcing for the GPO-based access
control to be evaluated and enforced.

Disabling mode
Give the ad_gpo_access_control option a value of disabled for the GPO-based access
control to be neither evaluated nor enforced.

NOTE
For a detailed list of available GPO parameters, as well as their descriptions and
default values, consult the sssd-ad(5) man page listed in the references section.

USING realmd FOR DIRECT INTEGRATION

SSSD has a number of different configuration parameters for each possible identity provider,
or for SSSD itself. This can lead to a complex management scheme of the various realms. In
addition, all domain information must be configured in advance before being formatted in the SSSD
configuration file. The realmd service simplifies that configuration: it can run a discovery search
to identify available Active Directory and IdM domains, then join the machine to the domain. It can
also set the required client services used to connect to the provider, and configure user access.

NOTE
Because SSSD supports multiple domains, realmd can discover and support
multiple domains as well.

The realmd service supports the following domain types:

• Microsoft Active Directory

• Red Hat Enterprise Linux Identity Management

The service supports the following domain clients:

• SSSD for both Red Hat Enterprise Linux Identity Management and Microsoft Active Directory.
• Winbind for Microsoft Active Directory.

Using realmd Tools

You can manage systems enrollment in a domain and define the domain users allowed to access
the local system resources with the realmd tools. The command-line utility for realmd is called
realm. To use the realm tool, you must specify the action, the entity, and the domain or the user
account that utility should perform, as follows:

realm command arguments

For example:

RH362-RHEL-7.4-en-1-20181003 181
CHAPTER 5 | Integrating IdM with Active Directory

[user@demo ~]$ realm join ad.lab.example.net realm permit user_demo

The following table lists available realm subcommands:

REALM SUBCOMMAND DESCRIPTION

discover Scans for domains on the network

join Adds a system to the specified domain

leave Removes a system from the specified domain

list Lists all configured domains for the system or all discovered
and configured domains

permit Enables access for specified users or for all users within a
configured domain to access the local system

deny Restrict access for specified users or for all users within a
configured domain to access the local system.

Discovering and Joining Identity Domains

The realm discover command prints the list of discovered domains and lists all the packages
that you must install in order to be able to enroll the system in the domain. The realm join
command sets up the local machine by configuring both the local system services and the entries
in the identity domain.

The following list describes the process of the realm join command:

1. Scans the specified domain and automatically detects the packages required to join the
system to the domain. This includes SSSD and PAM job packages.

2. Joins the domain by creating an account entry for the system in the directory.

3. Creates the /etc/krb5.keytab host Keytab file, configures the domain in SSSD, and
restarts the service.

4. Enables domain users for the system services for PAM and in the /etc/nsswitch.conf
configuration file.

When the realm discover is run without any options, it displays information about the default
DNS domain, that is, the domain assigned through the DHCP protocol, as follows:

[user@demo ~]$ realm discover

ad.lab.example.net
type: kerberos
realm-name: AD.lab.example.net
domain-name: ad.lab.example.net
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli

182 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

required-package: samba-common

You can also run a discovery for a specified domain by running the realm discover command
and pass the name of the domain as an option.

[user@demo ~]$ realm discover ad.lab.example.net

NOTE
The realmd system uses DNS SRV lookups to automatically locate the domain
controllers in the domain.

IMPORTANT
The NetworkManager service must be running for the realm discover
command, which depends on the D-Bus interface of NetworkManager.

If you do not use the NetworkManager, you must always specify the domain name
along the realm discover command.

realmd can discover both Active Directory and Identity Management domains. If both domains
exist in your environment, you can limit discovery results to a specific type of server by using the
--server-software option. For example:

[user@demo ~]$ realm discover --server-software=active-directory

One of the attributes returned in the discovery search is the login-policy attribute, which
shows whether domain users are allowed to log in as soon as the join is complete. Use the realm
permit command to allow logins that are not permitted by default.

Run the realm join domain command to join a domain. By default, the join is performed as the
domain administrator. For Active Directory, the administrator account is called Administrator,
whereas in IdM, the administrative user is admin. To connect as a different user, use the -U option
as follows:

[user@demo ~]$ realm join ad.lab.example.net -U user

The command attempts to connect without credentials first, but prompts you for a password if
required. If Kerberos is properly configured on a Linux system, joining can also be performed with a
Kerberos ticket for authentication by using the -U option as follows:

[user@demo ~]$ kinit user

[user@demo ~]$ realm join ad.lab.example.net -U user

The following procedure describes the enrollment process of a system in an Active Directory
domain:

1. Run the realm discover command to display information about the domain.

[user@demo ~]$ realm discover ad.lab.example.net

ad.lab.example.net
type: kerberos

RH362-RHEL-7.4-en-1-20181003 183
CHAPTER 5 | Integrating IdM with Active Directory

realm-name: AD.lab.example.net
domain-name: ad.lab.example.net
configured: no
server-software: active-directory
client-software: sssd

2. Run the realm join command and pass the domain name as an argument. If needed,
provide the administrator password.

[user@demo ~]$ realm join ad.lab.example.net

Password for Administrator: RedHat123^

3. To verify that the enrollment succeeded, ensure that you can log in as a user from the domain,
and that the user information is displayed properly.

[user@demo ~]$ id user@ad.lab.example.net

uid=1348601103(user@ad.lab.example.net) gid=1348600513(domain
group@ad.lab.example.net) \
groups=1348600513(domain group@ad.lab.example.net)

4. Use the ssh to log in to the client as the same user.

[user@demo ~]$ ssh -l user@ad.lab.example.net linux-client.ad.lab.example.net

user@ad.lab.example.net@linux-client.ad.lab.example.net's password: RedHat123^
Creating home directory for user@ad.lab.example.net.
[user@ad ~]$

5. Ensure that the id command displays the same information as the previous id
user@ad.lab.example.net command.

[user@ad ~]$ id
uid=1348601103(user@ad.lab.example.net) gid=1348600513(domain
group@ad.lab.example.net) \
groups=1348600513(domain
group@ad.lab.example.net) context=unconfined_u:unconfined_r:unconfined_t:s0-
s0:c0.c1023

Listing Domains
The realm list command lists every configured domain for the system, as well as the full details
and default configuration for that domain. This is the same information as that returned by the
realm discovery command, although this command only applies for a domain that is already
registered.

To list the registered domains, run the real list command as follows:

[user@demo ~]$ realm list --all \

--name-only ad.lab.example.net
ad.lab.example.net

Lists all discovered domains, both configured and nonconfigured.

Limits the results to the domain names and does not display the domain configuration details.

184 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Removing Systems from Active Directory Domains

Use the realm leave command to remove a system from an identity domain. The command
removes the domain configuration from SSSD and the local system. By default, the removal is
performed as the default administrator. If a different user is used to join the domain, perform the
removal as that user. To specify a different user, use the -U option:

[user@demo ~]$ realm leave ad.example.com \

-U 'AD.lab.example.net\user'

IMPORTANT
When a client leaves a domain, the computer account is not deleted from the
directory, only the local client configuration is removed. Run the command with the
--remove option to delete the account on the system.

Managing Login Permissions For Domain Users

Domain-side access control is applied by default, which means that login policies for domain users
are defined in the domain itself. You can override this default behavior in order to use client-side
access control. By doing so, login permissions are defined by local policies only. Use the realmd
command to configure access rules for allowing or denying users from that domain when client-
side access control is in use.

NOTE
These access rules either allow or deny access to all services on the system. More
specific access rules must be set on a specific system resource or in the domain. To
set the access rules, use realm deny --all to deny access to all users within the
domain.

Run the realm permit command to grant access to the specified user. Append
the --all option to grant access to all users or the -x option to deny access to a
specified user.

[user@demo ~]$ realm permit user@lab.example.net

[user@demo ~]$ realm permit 'AD.lab.example.net\user'
[user@demo ~]$ realm permit -x 'USER.LABEXAMPLE.COM\user'

IMPORTANT
Red Hat recommends only allowing access to specifically selected users or groups
rather than denying access to some users and enabling it for everyone else.
Therefore, it is not recommended to allow access to all by default while only denying
it to specified users with the realm permit -x user command.

To achieve this, maintain a default no access policy for all users, and only grant
access to selected users.

USING SAMBA FOR DIRECT INTEGRATION

Another way to integrate an IdM server in to an Active Directory domain is the use of Samba.
Samba implements the Server Message Block (SMB) protocol in Red Hat Enterprise Linux. The SMB
protocol is used to access resources on a server, such as file shares and shared printers. You can

RH362-RHEL-7.4-en-1-20181003 185
CHAPTER 5 | Integrating IdM with Active Directory

use Samba to authenticate Active Directory domain users to a Domain Controller. Additionally, you
can use Samba to share printers and local directories to other Samba clients in the network.

Using Winbind to Authenticate Domain Users

Samba's Winbind service provides an interface for the Name Service Switch (NSS) and enables
domain users to authenticate to Active Directory when logging into the local system. The
winbindd daemon allows you to enhance the configuration for sharing directories and printers
without installing additional software.

Use the realm join --client-software=winbind domain-name command to join an

Active Directory domain and use the Winbind service. The realm utility automatically updates the
configuration files, such as those for Samba, Kerberos, and PAM. For further information, consult
the resource Setting up Samba as a Domain Member section listed in the references section.

Using Samba Shares With SSSD

Prior to Red Hat Enterprise Linux 7.1, Winbind was the service that was accessing Samba shares.
In Red Hat Enterprise Linux 7.1 and later, you no longer need to run Winbind and SSSD in parallel
to access Samba shares. However, SSSD does not support all the services that Winbind provides:
SSSD does not support authentication using the NT LAN Manager (NTLM) or NetBIOS name lookup.
Use Winbind if you need these services. In IdM domains, Kerberos authentication and DNS name
lookup are available for the same purposes.

For most SSSD clients, Red Hat recommends using SSSD, as IdM uses SSSD by default to map
Active Directory users to UNIX users. Using Winbind for mapping Samba users to Linux users,
instead of using SSSD can result in inconsistent mapping.

The Samba file sharing protocol is widely used on Microsoft Windows machines. SSSD supports
seamless integration with Samba share in Red Hat Enterprise Linux environments, assuming a
trust between the IdM server and the Active Directory server. To access a Samba share, the system
must be able to translate Windows SIDs to Linux POSIX UIDs and GIDs. SSSD clients use the
SID-to-ID or SID-to-name algorithm, which enables the mapping of the identifiers.

Run the alternatives utility to verify that the system uses SSSD for accessing Samba shares.
The utility displays the library currently in use:

[user@demo ~]$ alternatives --list | \

grep -E cifs\|libwbclient
cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so
libwbclient.so.0.11-64 auto /usr/lib64/sssd/modules/libwbclient.so.0.11.0

The following procedure describes how to switch between SSSD and Winbind plug-ins that are
used for accessing SMB shares from SSSD clients.

1. Verify that the winbind service is running on the Linux server.

[user@demo ~]$ systemctl is-active winbind.service

active

2. Run the alternatives command with the --set option to set an alternative.

[user@demo ~]$ alternatives --set \

cifs-idmap-plugin /usr/lib/cifs-utils/idmapwb.so

186 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Conﬁguring SSSD Clients to Run a Samba Server Without

Winbind
If you run an IdM server and Samba in your environment, you can configure the Samba server
to use Kerberos to authenticate IdM users connecting to a share, as detailed in the following
procedure. However, accessing Samba shares from Windows clients in this configuration is not
supported.

1. From the IdM server, run the ipa-adtrust-install command to configure the master to
manage object classes and attributes specific to Samba.

2. Install the required packages for IdM and join the client to the domain, as detailed in Managing
IdM Clients

3. Install the Samba server and the sssd-libwbclient packages.

[root@demo ~]# yum install samba sssd-libwbclient

4. Create the Common Internet File System (CIFs) Kerberos principal for Samba server.

[root@demo ~]# ipa service-add \

cifs/samba_server.idm.lab.example.net

5. Retrieve the Kerberos Keytab for the CIFS principal and store it in the /etc/samba/
samba.keytab Keytab file.

[root@demo ~]# ipa-getkeytab \

-p cifs/samba_server.idm.lab.example.net \
-k /etc/samba/samba.keytab

6. Set the following parameters in the [global] section of the /etc/samba/smb.conf

configuration file.

workgroup = IDM
realm = IDM.lab.example.net
security = ads
dedicated keytab file = FILE:/etc/samba/samba.keytab
kerberos method = dedicated keytab

7. Optionally, set up file and printer shares.

8. Run the testparm to verify the configuration. If the utility does not return any error, the
configuration is valid.

9. Use the firewall-cmd utility to open the required ports, make the configuration permanent.

[root@demo ~]# firewall-cmd --add-service=samba

success
[root@demo ~]# firewall-cmd --add-service=samba --permanent
success

10. Enable and start the smb service.

[root@demo ~]# systemctl enable smb --now

RH362-RHEL-7.4-en-1-20181003 187
CHAPTER 5 | Integrating IdM with Active Directory

The following procedures detail the steps for listing the Samba server shares:

1. Install the samba-client package

[root@demo ~]# yum install samba-client

2. Authenticate to the Kerberos server and list the shares.

[root@demo ~]# kinit user name

[root@demo ~]# smbclient -k -U user name \
-L samba_server.idm.lab.example.net

REFERENCES
Further information is available in the knowledge base on Joining SSSD to domains in
different forests at
https://access.redhat.com/solutions/2710131

Further information is available in the Red Hat Enterprise Linux 7 Windows Integration
Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/windows_integration_guide/index

Further information is available in the chapter on Configuring SSSD in the Red Hat
Enterprise Linux 7 System-Level Authentication Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/system-level_authentication_guide/index

Identity Management for UNIX

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-
server-2008-R2-and-2008/cc772571(v=ws.11)

sssd-ad(5) man page.

realm(8) man page.

Further information is available in the section on Setting up Samba as a Domain

Member in the Red Hat Enterprise Linux 7 System Administrator Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/system_administrators_guide/

188 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

GUIDED EXERCISE

ACCESSING ACTIVE DIRECTORY USING

DIRECT INTEGRATION
In this exercise, you will connect a Red Hat Enterprise Linux system directly to Active
Directory.

OUTCOMES
You should be able to perform a direct Active Directory connection and control user access to
a Red Hat Enterprise Linux system.

In this exercise you use the existing ad virtual machine. Ensure that the ad virtual machine
is running. This virtual machine server is the Primary Domain Controller for the existing
example.net Active Directory domain. The Administrator user password is set to
password123!.

Log in to workstation as student using student as the password. Run the lab ad-direct
setup command to configure the environment.

[student@workstation ~]$ lab ad-direct setup

1. From workstation, open a new terminal and log in to the replica1 system as the
student user, then become root.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[sudo] password for student: student
[root@replica1 ~]#

2. Using Winbind direct connection method, configure the replica1 system to be a member
of the Active Directory example.net domain. Use the realm command to add the
replica1 system to the Active Directory domain.
2.1. On the replica1 system, install the required packages:

• realmd
• oddjob
• oddjob-mkhomedir
• sssd
• adcli
• krb5-workstation
• samba-common-tools
• samba-winbind-clients
• samba-winbind

[root@replica1 ~]# yum install realmd oddjob oddjob-mkhomedir sssd adcli \

krb5-workstation samba-common-tools samba-winbind-clients samba-winbind
...output omitted...
RH362-RHEL-7.4-en-1-20181003 189
CHAPTER 5 | Integrating IdM with Active Directory

Is this ok [y/d/N]: y
...output omitted...
Complete!

2.2. Change the existing replica1.lab.example.net client host DNS configuration

to use the ad.example.net server. Use the nmcli connection modify
command to set the eth0 ipv4.dns option to the Active Directory server IP address
of 172.25.250.13. Use the nmcli connection up command to activate the
DNS change.

[root@replica1 ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.13

[root@replica1 ~]# nmcli connection up "System eth0"
Connection successfully activated (D-Bus active path: /org/freedesktop/
NetworkManager/ActiveConnection/4)

2.3. Use the dig command to query the SRV records for the Active Directory domain.

[root@replica1 ~]# dig -t SRV _ldap._tcp.example.net

... output omitted ...
;; ANSWER SECTION:
_ldap._tcp.example.net. 600 IN SRV 0 100 389 ad.example.net.

;; ADDITIONAL SECTION:
ad.example.net. 3600 IN A 172.25.250.13
... output omitted ...
[root@replica1 ~]# dig -t SRV _kerberos._tcp.example.net
... output omitted ...
;; ANSWER SECTION:
_kerberos._tcp.example.net. 600 IN SRV 0 100 88 ad.example.net.

;; ADDITIONAL SECTION:
ad.example.net. 3600 IN A 172.25.250.13
... output omitted ...
[root@replica1 ~]# dig -t SRV _ldap._tcp.dc._msdcs.example.net
... output omitted ...
;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.example.net. 600 IN SRV 0 100 389 ad.example.net.

;; ADDITIONAL SECTION:
ad.example.net. 3600 IN A 172.25.250.13
... output omitted ...

2.4. Use the realm command to discover the example.net Active Directory domain.

[root@replica1 ~]# realm -v discover example.net

* Resolving: _ldap._tcp.example.net
* Performing LDAP DSE lookup on: 172.25.250.13
! Received invalid or unsupported Netlogon data from server
example.net
type: kerberos
realm-name: EXAMPLE.NET
domain-name: example.net
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob

190 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools

2.5. Use the realm join command with the --client-software=winbind

example.net option to join the Active Directory domain using winbind. When
prompted, enter password123! as the password.

[root@replica1 ~]# realm join --client-software=winbind example.net

Password for Administrator: password123!

2.6. Run the realm list command to examine the client configuration.

[root@replica1 ~]# realm list

example.net
type: kerberos
realm-name: EXAMPLE.NET
domain-name: example.net
configured: kerberos-member
server-software: active-directory
client-software: winbind
required-package: oddjob-mkhomedir
required-package: oddjob
required-package: samba-winbind-clients
required-package: samba-winbind
required-package: samba-common-tools
login-formats: ADEXAMPLE\%U
login-policy: allow-any-login

Notice that the client-software type is set to winbind.

2.7. Use the getent command to verify details of the aduser01 Active Directory user.

[root@replica1 ~]# getent passwd example.net\\aduser01

EXAMPLE.NET\aduser01:*:10000:10000::/home/aduser01@EXAMPLE.NET:/bin/bash

Notice that the POSIX user ID. The ID range for the domain users is defined in the /
etc/samba/smb.conf Samba configuration file.
2.8. Use the wbinfo --all-domains command to list all available domains.

[root@replica1 ~]# wbinfo --all-domains

BUILTIN
REPLICA1
ADEXAMPLE

2.9. Allow samba services through the firewall.

[root@replica1 ~]# firewall-cmd --add-service=samba

success
[root@replica1 ~]# firewall-cmd --add-service=samba --permanent

RH362-RHEL-7.4-en-1-20181003 191
CHAPTER 5 | Integrating IdM with Active Directory

success

2.10. Install the samba package.

[root@replica1 ~]# yum install samba

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

2.11. Start the smb service.

[root@replica1 ~]# systemctl start smb

2.12. Enable sharing of home directories using SMB by changing the SELinux boolean
value for samba_enable_home_dirs to on.

[root@replica1 ~]# semanage boolean --modify \

--on samba_enable_home_dirs

2.13. Log out from the replica1 server console.

2.14. From workstation, use SSH to log in to the replica1 host as the
administrator@ADEXAMPLE Active Directory user. In this example, use the
ADEXAMPLE NetBIOS domain name.

[student@workstation ~]$ ssh administrator@ADEXAMPLE@replica1.lab.example.net

Creating home directory for administrator@example.net.
[ADEXAMPLE\administrator@replica1 ~]$

NOTE
When logging in to a system that uses Winbind to access Active Directory, use the
user@NETBIOS schema.

Leave the console open and proceed to the next step.

192 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

3. Use Windows to access the administrator user home directory on

replica1.lab.example.net server. In that directory, create a new text file called
test.txt .
3.1. Log in to the Active Directory server as the Administrator user with
password123! as password.
3.2. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field, type \\replica1.lab.example.net and press Enter.
3.3. After a few seconds a window comes up, with the content of
replica1.lab.example.net server.
3.4. In the newly opened replica1.lab.example.net window, double-click the
administrator directory.
3.5. Within that SMB shared directory, right-click on the empty space of the window and
from the displayed menu choose New → Text Document object.
3.6. Give the new document the test name.
3.7. Go back to the replica1 console. As the administrator Active Directory user,
use the ls to confirm the creation of a new file within that user's home directory.

[ADEXAMPLE\administrator@replica1 ~]$ ls
test.txt

The existence of the test.txt confirms that the direct integration of the
replica1.lab.example.net server with Active Directory works as expected.

4. Use su - to switch identity to the root user. When prompted, provide redhat as
password.

[ADEXAMPLE\administrator@replica1 ~]# su -
Password: redhat
[root@replica1 ~]#

5. Use the realm leave --remove command to leave the Active Directory domain. When
prompted, type password123! as the Administrator password.

[root@replica1 ~]# realm leave --remove

Password for Administrator: password123!

NOTE
You have left the Active Directory domain. In the next step, you join the domain with
a different option, using SSSD.

6. Use SSSD and the realm command to directly join the example.net domain. When
prompted, type password123! as the Administrator password.

[root@replica1 ~]# realm join example.net

Password for Administrator: password123!

RH362-RHEL-7.4-en-1-20181003 193
CHAPTER 5 | Integrating IdM with Active Directory

7. From workstation, use SSH to log in to the replica1 host as the

aduser01@example.net Active Directory user.

[student@workstation ~]$ ssh aduser01@example.net@replica1.lab.example.net

Creating home directory for aduser01@example.net.
[aduser01@example.net@replica1 ~]$

NOTE
Notice the difference between Winbind and SSSD in the user specification. SSSD
uses the user@domain schema.

8. Run the realm list command to review details about the domain that the
replica1.lab.example.net server is a member of.

[aduser01@example.net@replica1 ~]$ realm list

example.net
type: kerberos
realm-name: EXAMPLE.NET
domain-name: example.net
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U@example.net
login-policy: allow-permitted-logins

Notice that this time the client-software setting is set to sssd.

9. Use the su - command and provide redhat as the password to switch identity to the root
user.

[aduser01@example.net@replica1 ~]$ su -
Password:redhat
[root@replica1 ~]#

10. Run the realm deny -a command with the -R example.net option to deny access to
all users within the example.net domain.

[root@replica1 ~]# realm deny -a -R example.net

11. Use the realm list command to verify that the domain user's login-policy is set to deny-
any-login

[root@replica1 ~]# realm list

example.net
type: kerberos

194 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

realm-name: EXAMPLE.NET
domain-name: example.net
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U@example.net
login-policy: deny-any-login

12. On workstation open another terminal. Use SSH to log in to the replica1 server as the
aduser01@example.net user.

[student@workstation ~]$ ssh aduser01@example.net@replica1

Authentication failed.

13. Change the configuration so that the Active Directory user aduser01 can log in to the
system using the ssh command. Use the realm permit aduser01@example.net -R
example.net command to allow that user to log in.

[root@replica1 ~]# realm permit aduser01@example.net -R example.net

14. On workstation open another terminal. Use SSH to log in to the replica1 server as the
aduser01@example.net user.

[student@workstation ~]$ ssh aduser01@example.net@replica1

[aduser01@example.net@replica1 ~]$

15. Log out from the replica1 server and use the ssh command a second time to access the
same server, this time as the aduser02@example.net user.

[student@workstation ~]$ ssh aduser02@example.net@replica1

Authentication failed.

Notice how the aduser02@example.net is denied access to the system. You have
granted the permission to log in to the system to the aduser01@example.net user only.
All other users from that Active Directory domain are rejected because of the specified login
policy.

16. From workstation, log in to the replica1 server as the student user, then become
root.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[sudo] password for student: student
[root@replica1 ~]#

RH362-RHEL-7.4-en-1-20181003 195
CHAPTER 5 | Integrating IdM with Active Directory

17. Use the realm permit -a command with the -R example.net option to allow access
to all users within the example.net domain.

[root@replica1 ~]# realm permit -a -R example.net

18. Run the realm list command to verify that the domain user's login-policy is set to
allow-realm-logins

[root@replica1 ~]# realm list

19. Create a new Active Directory Global Policy setting in order to deny access to all users
except the aduser01 user. Configure SSSD to respect the SSH, and console access global
policies as defined in the Active Directory server.
19.1. From the replica1 server, edit the /etc/sssd/sssd.conf configuration file
as the root user. Under the [domain/example.net] section, add the following
setting ad_gpo_access_control = enforcing.

[root@replica1 ~]$ vim /etc/sssd/sssd.conf

...output omitted...
[domain/example.net]
ad_domain = example.net
krb5_realm = EXAMPLE.NET
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
ad_gpo_access_control = enforcing

19.2. Restart the sssd service.

[root@replica1 ~]$ systemctl restart sssd

196 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

20. Within the Active Directory structure, create a new Organizational Unit (OU) called Linux
Servers.
20.1. Log in to the Active Directory server as user Administrator with password123!
as password. In the Server Manager dashboard, click the Tools drop-down menu.
20.2. From the list of available tools, click the Active Directory Users and Computers tool.
20.3. In the left pane, right-click the example.net domain and choose New followed by
Organizational Unit
20.4. Using the New Object - Organizational Unit dialog window, type in the new name of
the OU, Linux Servers, in the Name field. Click the OK button.
20.5. In the left pane of the Active Directory Users and Computers dialog window, expand
the example.net object. Click the Computers object from the drop-down menu.
In the right pane, click and drag the REPLICA1 Computer Object into the Linux
Servers Organizational Unit. When the Active Directory Domain Services window
appears, click the Yes button to accept moving the Computer Object.

NOTE
Remember that a direct connection to a Microsoft server might require additional
CAL licenses for the user or the device that is connecting. For more information
about Microsoft licensing requirements, consult the documents available at https://
www.microsoft.com/en-us/licensing/product-licensing/client-access-license.aspx

21. Use the Group Policy Management Editor to create a new Group Policy Object (GPO)
for the Linux Servers OU you created. This new policy controls the remote access to the
replica1.lab.example.net server.
21.1. In the Server Manager dashboard, click the Tools menu. From the list, choose the
Group Policy Management tool.
21.2. In the left pane, expand the Forest: example.net → Domains → example.net
objects. Right click the Linux Servers OU, and choose Create a GPO in this
domain, and Link it here....
21.3. In the new New GPO dialog window, type in Allow SSH as the name for the new
GPO, and click the OK button.
21.4. In the left pane, select the Linux Servers OU. In the right pane, right click the
Allow SSH GPO and choose Edit.
21.5. In the left pane of the Group Policy Management Editor dialog window, expand
the Computer Configuration → Policies objects. Expand the Windows Settings →
Security Settings → Local Policies objects. Click the User Rights Assignment.
21.6. In the right pane, double-click the Allow log on through Remote Desktop Services
policy.
21.7. In the Allow log on through Remote Desktop Services Properties window, click the
check box next to Define these policy settings:.
21.8. Click the Add User or Group button. In the Add User or Group window, click the
Browse button.
21.9. A new Select Users, Computers, Service Accounts, or Groups window opens. In the
Enter the object names to select (examples) text field, type in the aduser01 user
name. Click the Check Names button, followed by the OK button three times.

RH362-RHEL-7.4-en-1-20181003 197
CHAPTER 5 | Integrating IdM with Active Directory

22. On workstation, open a terminal and use SSH to log in to the replica1 system as the
aduser01 user.

[student@workstation ~]$ ssh aduser01@example.net@replica1.lab.example.net

[aduser01@example.net@replica1 ~]$

Notice how the GPO policy allows aduser01 user remote access to the replica1 server.

23. Log out from the replica1 server and try to log in again using the aduser02 and
aduser03 user credentials. This fails, because the current GPO defined for the replica1
server in Active Directory permits access only for the aduser01 user.

[student@workstation ~]$ ssh aduser02@example.net@replica1.lab.example.net

Authentication failed.
[student@workstation ~]$ ssh aduser03@example.net@replica1.lab.example.net
Authentication failed.

Note, however, that this GPO only prevents those users from remotely accessing the server.
To prevent the users from logging in locally, you must define the Allow log on locally
policy within the new created GPO.

Cleanup
From workstation, run the lab ad-direct cleanup command to clean up this exercise.

[student@workstation ~]$ lab ad-direct cleanup

This concludes the guided exercise.

198 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

ACCESSING ACTIVE DIRECTORY USING A

TRUST RELATIONSHIP

OBJECTIVES
After completing this section, students should be able to:

• Describe the components of one-way and two-way trusts

• Configure a one-way trust relationship

INTRODUCING CROSS-FOREST TRUSTS

Kerberos implements trusts. By using trusts, principals from one Kerberos realm can request a
ticket to a service in another Kerberos realm. By using this ticket, principals authenticate against
resources on machines belonging to another realm. Kerberos can also create a relationship
between two separate Kerberos realms, which is referred to as a cross-realm trust.

IdM supports the configuration of a cross-forest trust between an IdM domain and an Active
Directory domain. Realms that are part of a trust use a shared pair of a ticket and key, and
a member of one realm is also member of both realms. The following diagram describes the
interaction between IdM and Active Directory services through a trust:

Figure 5.1: Managing trusts between IdM and Active Directory domains

RH362-RHEL-7.4-en-1-20181003 199
CHAPTER 5 | Integrating IdM with Active Directory

One-way and Two-way Trusts

Red Hat Enterprise Linux supports forest trust to Active Directory, which can be one-way or
bidirectional. In both cases, IdM servers are able to exchange with Active Directory DCs, and any
Active Directory server can communicate with any IdM machine.

• One-way trust enables Active Directory users and groups to access resources in IdM, but not the
other way around. The IdM domain trusts the Active Directory forest, but the Active Directory
forest does not trust the IdM domain.

This is the default mode for creating a trust.

• Two-way trust enables Active Directory users and groups to access resources in IdM. However,
this trust in IdM does not give the users any additional privileges compared to a one-way trust in
Active Directory.

Active Directory Trusts and Cross-Forest Trusts

Whereas Kerberos realms manage authentication, there are other services in use for managing
identity and authorization for servers running in the Kerberos realm, such as LDAP, DNS, or
certificate services. As such, administrators must not only rely on establishing a Kerberos cross-
realm trust but must also configure the services and resources in the other realm.

Multiple Active Directory domains can be grouped together into an Active Directory forest. The
first domain in the forest is the root domain, and remains active for the life cycle of the deployment.
IdM domains cannot be part of an existing Active Directory forest, and are always seen as a
separate forest. When a trust relationship is established between two separate forest root domains,
which allows users and services from different Active Directory forests, the trust is called an Active
Directory cross-forest trust.

IdM can also be part of trust relationships with different Active Directory forests. After a trust is
established, additional trusts with other forests can be added later, following the same commands
and procedures. IdM can trust multiple, entirely unrelated forests at the same time, allowing users
from such unrelated Active Directory forests to access resources in the same shared IdM domain.

Trust Flow and One-way Trusts

There are many ways to configure Active Directory trusts between subdomains, root domains,
and forests. The way that identifies how information moves between domains is called trust flow.
Trusted domains contain users, and trusting domains allow access to resources; in a one-way trust,
trusts flow only in one direction: users have access to the trusting domain's resources, but users in
the trusting domains cannot access resources in the trusted domain.

In the following figure, the DOMAIN A domain is a domain trusted by the DOMAIN B domain, but
the DOMAIN B domain is not trusted by the DOMAIN A domain.

Figure 5.2: A one-way trust in Active Directory

200 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Transitive and Non-Transitive Trusts

You can configure transitive and non-transitive trusts between domains. With transitive trusts, a
domain trusts another domain and any other domain trusted by the second domain.

The following diagram describes transitive trust between three domains. The DOMAIN C domain
trusts DOMAIN A because it trusts DOMAIN B.

Figure 5.3: Transitive trust between domains

With non-transitive trust, the trust is limited only to the domains explicitly specified. Within an
Active Directory forest, trust relationships between domains are usually two-way and transitive
by default. Trust between two Active Directory forests is a trust between two forest root domains,
which can be two-way or one-way. The transitivity of the cross-forest trust is explicit, which means
that any domain trust within an Active Directory forest that leads to the root domain of the forest is
transitive over the cross-forest trust. Separate cross-forest trusts are not transitive, therefore, you
must establish an explicit cross-forest trust between each Active Directory forest root domain to
another Active Directory forest root domain.

An IdM domain represents a separate Active Directory forest with a single Active Directory domain.
Through a cross-forest trust between an Active Directory forest root domain and an IdM domain,
users from the Active Directory forest can interact with Linux machines and services from the IdM
domain.

The following diagram describes users from an Active Directory domain accessing resources in an
IdM domain after the trust has been established between the two domains.

Figure 5.4: Trust direction between two domains

TRUST ARCHITECTURE IN IDM

The IdM server must be able to identify Active Directory entities and process their group
memberships for access control. The Microsoft Privilege Account Certificate (MS-PAC) contains
the required information about users, which includes security identifiers, domain user names, and
group memberships.

RH362-RHEL-7.4-en-1-20181003 201
CHAPTER 5 | Integrating IdM with Active Directory

There are two components for analyzing the data in the account certificate on a Kerberos ticket:

1. SSSD performs identity lookups on Active Directory and retrieves user and group security
identifiers for authorization. SSSD caches user, group, and ticket information for users.

SSSD also maps Kerberos and DNS domains.

2. IdM associates Active Directory users with IdM groups for IdM policies and access.

Access control rules and policies for Linux domain administration, such as SELinux, sudo, and
host-based access controls are defined and applied through the IdM server. Any access control
rules set in Active Directory are not evaluated or used by IdM servers, and the only relevant Active
Directory configuration is group membership.

Active Directory Users and IdM Groups

You can add individual Active Directory users and Active Directory groups to IdM groups. User
groups are required to set access permissions, host-based access control, sudo rules, and other
controls on IdM users. These groups grant or restrict access to IdM domain resources. Active
Directory users and groups can be added directly to IdM user groups.

In order to add users and groups to the IdM server, add Active Directory users to a non-POSIX IdM
external group, then to a local IdM POSIX group. The POSIX group is then used for user and role
management of the Active Directory users.

For more information on handling non-POSIX groups in IdM, consult the section on Active Directory
Users and Identity Management Groups in the Windows Integration Guide listed in the references
section.

Non-POSIX External Groups and Security ID Mapping

IdM uses LDAP for managing groups, which are expressed by specifying a distinguished name (DN)
of an LDAP object that is a member of a group. Active Directory entries are not synchronized or
copied over to IdM, which means that Active Directory users and groups have no LDAP objects in
the LDAP server, so they cannot be directly used to express group membership in the IdM LDAP.
For this reason, IdM creates non-POSIX external groups, referenced as normal IdM LDAP objects to
signify group membership for Active Directory users and groups in IdM.

Security IDs (SIDs) for non-POSIX external groups are processed by SSSD, which maps the SIDs
of groups in Active Directory to POSIX groups in IdM. In Active Directory, SIDs are associated
with user names. When a user name is used to access IdM resources, SSSD in IdM resolves the
user name to its security ID before retrieving the information for that SID in the Active Directory
domain.

NOTE
For more information on Active Directory Privilege Account Certificates and IdM
tickets, consult the section on Active Directory PACs and IdM Tickets in the Windows
Integration Guide listed in the references section.

ID Ranges
Linux users are assigned a user ID (UID) number and a private group. The private group identifier
number is the same as the user ID number. Whereas in a Linux environment, this does not create a
conflict, in Active Directory, the security ID number must be unique for every object in the domain.
The trusted users in Active Directory require a UID and GID number in Linux systems.

These UID and GID numbers can be generated by IdM, however, if Active Directory entries already
have UIDs and GIDs numbers assigned, assigning different numbers creates a conflict. Therefore,

202 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

to avoid conflict, use the POSIX attributes defined by Active Directory instead of having IdM
generate new values. These attributes include the UID, the GID number, and preferred login shell.

IMPORTANT
Active Directory stores a subset of information for all objects in a global catalog,
which includes every entry for every domain in a forest. Red Hat recommends that
you replicate the attributes to the global catalog first.

When a trust is created, IdM automatically detects which ID range to use and creates a unique
range for Active Directory domains added to the trust. Pass one of the following --range-type
options to the ipa trust-add command to define the range:

• The ipa-ad-trust range option uses the IDs generated by IdM based on the security ID. If
IdM generates the security IDs using the SID-to-POSIX ID mapping, ID ranges for Active
Directory and IdM users and groups must have unique and non-overlapping ranges.

[root@demo ~]$ ipa trust-add --range-type=ipa-ad-trust

• The ipa-ad-trust-posix range option uses IDs defined in POSIX attributes in Active
Directory entries. IdM obtains the POSIX attributes, including uidNumber and gidNumber from
Active Directory's global catalog or from the domain controller.

[root@demo ~]$ ipa trust-add --range-type=ipa-ad-trust-posix

If there are no ID conflicts, then the ID numbers that are generated are unique, so no ID
validation or ID range is required.

TRUST CONTROLLERS AND TRUST AGENTS

IdM can be configured in two ways for managing trust to Active Directory domains: trust agents and
trust controllers:

• Trust agents are IdM servers that can perform identity lookups against Active Directory domain
controllers.

• Trust controllers are IdM servers which are also trust agents and run the Samba suite. Active
Directory domain controllers contact trust controllers when establishing and verifying the trust.

IMPORTANT
Trust controllers run a greater amount of network-facing services compared to trust
agents, so they present a greater attack surface for potential intruders.

The following table describes the different capabilities between trust agents and trust controllers.

CAPABILITY TRUST AGENTS TRUST

CONTROLLERS

Resolve Active Directory users and groups Yes Yes

Enroll IdM clients that run services accessible by Yes Yes

users from trusted Active Directory forests

Manage trust; for example, adding a trust No Yes

agreement

RH362-RHEL-7.4-en-1-20181003 203
CHAPTER 5 | Integrating IdM with Active Directory

NOTE
To prevent failures in the trust, deploy at least two trust controllers per IdM
deployment and two trust controllers in each data center.

CREATING CROSS-FOREST TRUSTS IN ACTIVE

DIRECTORY AND IDM
Establishing a trust is a three-steps process, as described in the following list. The following
sections describe each of these steps.

1. Prepare the IdM server for the trust.

2. Create a trust agreement.

3. Verify the Kerberos configuration.

Prerequisites for Establishing a Trust

Before establishing a trust, consider the following requirements for establishing a trust between
IdM and Active Directory domains.

• Windows Server 2008 and Windows Server 2012 R2 support establishing a trust relationship at
the forest and domain functional levels.

Windows Server 2012 R2 and Windows Server 2016 are supported and tested for establishing
trusts with the aforementioned functional levels.

• All DNS records must be resolvable from all DNS domains in the trust and each system must
have its own unique primary DNS domain configured, such as ad.example.net for the Active
Directory domain and idm.example.net for the IdM domain.

WARNING
IdM does not work correctly when the IdM domain is a parent domain of the Active
Directory domain, for example: example.net or identity.example.net for IdM
and ad.example.net or ad.identity.example.net for Active Directory.

Consult the bug report BZ#1421869 [https://bugzilla.redhat.com/show_bug.cgi?

id=1421869] for more information.

NOTE
It is not possible for Active Directory or IdM to share the primary DNS domain with
another system for identity management. Consult the section on Host Name and
DNS Configuration Requirements in the Linux Domain Identity, Authentication, and
Policy Guide listed in the references section.

To ensure that the services hosted by the IdM server are resolvable from the IdM domain server
used for establishing trust, perform the following steps:

1. Run a DNS query for the Kerberos over UDP and LDAP over TCP service records.

[root@demo ~]$ dig +short -t SRV _kerberos._udp.demo.example.net

0 100 88 idm.demo.example.net.
[root@demo ~]$ dig +short -t SRV _ldap._tcp.idm.demo.example.net

204 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

0 100 389 idm.demo.example.net.

2. Run a DNS query for the TXT record with the IdM Kerberos realm name. The value is
expected to match the Kerberos realm that you specified when installing the IdM server.

[root@demo ~]$ dig +short -t TXT _kerberos.idm.demo.example.net.

"DEMO.EXAMPLE.NET"

3. Run a DNS query for the domain controller over UDP and LDAP over TCP service records.

[root@demo ~]$ dig +short -t SRV _kerberos._udp.dc._msdcs.idm.demo.example.net.

0 100 88 idm.demo.example.net.
[root@demo ~]$ dig +short -t SRV _ldap._tcp.dc._msdcs.idm.demo.example.net.
0 100 389 idm.demo.example.net.

To ensure that the IdM server is able to resolve service records for Active Directory, run a DNS
query for Kerberos over UDP and LDAP over TCP service records.

[root@demo ~]$ dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.net.

0 100 88 ad.example.net.
[root@demo ~]$ dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.net.
0 100 389 ad.example.net.

• Kerberos realm names must be the same as the primary DNS domain names, with all letters
uppercase. For example, if the domain names are ad.example.com and idm.example.com,
the Kerberos realm names must be AD.EXAMPLE.COM and IDM.EXAMPLE.COM.

• The IdM domain and Active Directory domain must have different NetBIOS names.

• The IdM system must have the IPv6 protocol enabled in the kernel. If IPv6 is disabled, the CLDAP
plug-in used by the IdM services fails to initialize.

• Both the Active Directory server and the IdM server must have their clocks in sync. Red Hat
recommends the use of a NTP server in the environment.

• Open the following firewall ports for accessing services in IdM and Active Directory servers. The
table lists the port requirements for Active Directory.

For IdM ports, consult the Port Requirements in the Linux Domain Identity, Authentication, and
Policy Guide listed in the references section.

SERVICE PORT PROTOCOL

Endpoint resolution portmapper 135 TCP

NetBIOS-DGM 138 TCP and UDP

NetBIOS-SSN 139 TCP and UDP

Microsoft-DS 445 TCP and UDP

Endpoint mapper listener range 1024-1300 TCP

AD Global Catalog 3268 TCP

LDAP 389 TCP and UDP

RH362-RHEL-7.4-en-1-20181003 205
CHAPTER 5 | Integrating IdM with Active Directory

Preparing the IdM Server for Trust

The following procedure describes the necessary steps for preparing an IdM server for trust.

1. Install the required packages and run the ipa-adtrust-install utility. This utility
adds DNS service records required for Active Directory trusts. These records are created
automatically if IdM is installed with an integrated DNS server. If IdM is not installed with an
integrated DNS server, the ipa-adtrust-install command prints a list of service records
that must be manually added to DNS before proceeding with establishing the trust.

[root@demo ~]$ yum install ipa-server ipa-server-trust-ad samba-client

[root@demo ~]$ ipa-adtrust-install

2. Start the smb daemon and use the smbclient utility to verify that Samba responds to
Kerberos authentication from the IdM.

[root@demo ~]$ systemctl start smb

[root@demo ~]$ smbclient -L ipaserver.demo.example.net -k
lp_load_ex: changing to config backend registry
...output omitted...

Creating a Trust Agreement

To create a trust agreement for the Active Directory domain and the IdM domain, run the ipa
trust-add command:

[root@demo ~]$ ipa trust-add example.net \

--type=ad \
--admin=administrator \
--password

NOTE
The command sets up a one-way trust by default. To establish a two-way trust, pass
the --two-way=true option, as shown in the following screen.

[root@demo ~]$ ipa trust-add example.net \

--type=ad \
--admin=administrator \
--password \
--two-way=true

Verifying the Kerberos Conﬁguration

The following procedure describes the necessary steps for verifying the Kerberos configuration
upon establishing a trust agreement.

1. To verify the Kerberos configuration, retrieve a ticket for an IdM user. The user should be able
to request service tickets.

• To verify a two-way trust, request a ticket for an IdM user.

[root@demo ~]$ kinit user

[root@demo ~]$ kvno -S host idm.demo.example.net

206 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Request service tickets for a service within the Active Directory domain.

[root@demo ~]$ kvno -S cifs ad.demo.example.net

If successfully granted, a cross-realm ticket-granting ticket is listed with all other requested
tickets. The TGT is named krbtgt/AD.DOMAIN@IDM.DOMAIN.

• To verify a one-way trust, request a ticket for an Active Directory user.

[root@demo ~]$ kinit user@ad.demo.example.net

[root@demo ~]$ kvno -S host idm.demo.example.net

Request service tickets for a service within the IdM domain:

[root@demo ~]$ kvno -S host idm.example.net

If granted, a cross-realm ticket-granting ticket is listed with all other requested tickets. The
TGT is named krbtgt/IDM.DOMAIN@AD.DOMAIN.

2. Log in to a client with an Active Directory user:

[user@prompt ~]$ ssh AD user05@demo.net@client.demo.example.net

3. Verify the Active Directory trust agreements:

a. Log in to the Active Directory server as the administrator user and access the Active
Directory Domains and Trusts tool from the Server Manager dashboard.

b. Review the trust type for the domain. Ensure that the trust type reads Forest and that
the direction of the trust is set to Incoming.

Creating a Two-way Trust with Shared Secrets

Shared secrets are passwords known to trusted peers which can be used by other domains to join
the trust. Using a shared secret, you can configure a two-way trust within Active Directory. The
shared secret is stored as a Trusted Domain Object (TDO) within the trust configuration.

IdM supports creating a two-way trust using a shared secret instead of the Active Directory
administrator credentials. Setting up such a trust requires the administrator to create the shared
secret in Active Directory and manually validate the trust.

NOTE
Shared secrets can only be used to create a two-way trust. To establish a one-way
trust, use administrator credentials.

The following procedure describes the necessary steps for creating a two-way trust with a shared
secret.

1. Configure a trust in the Active Directory Domains and trusts console, which includes:

• Creating a new trust

• Giving the trust the IdM domain name with a forest type of trust

RH362-RHEL-7.4-en-1-20181003 207
CHAPTER 5 | Integrating IdM with Active Directory

• Specifying that this is a two-way trust and a forest-wide authentication

• Setting the trust password

NOTE
The same password must be used when configuring the trust in IdM

2. Create a trust agreement. When running the ipa trust-add command, use the --type, --
trust-secret, and --two-way=True options, and omit the --admin option.

3. On the IdM server, ensure that the trust relationship is established by running the ipa
trust-show command.

NOTE
Run the ipa trust-fetch-domains domain to ensure that you can obtain a
Common Internet File System (CIFS) ticket-granting ticket before running the ipa
trust-show command.

REFERENCES
Further information is available in the Red Hat Enterprise Linux 7 Windows Integration
Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/windows_integration_guide/index

Red Hat Enterprise Linux 7 Domain Identity, Authentication, and Policy Guide Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/linux_domain_identity_authentication_and_policy_guide/index

• Host name and DNS Configuration Requirements.

• Port Requirements.

208 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

GUIDED EXERCISE

ACCESSING ACTIVE DIRECTORY USING A

TRUST RELATIONSHIP
In this exercise, you will create an IdM one-way trust relationship to Active Directory and use
an Active Directory account to verify the trust configuration.

OUTCOMES
You should be able to establish a one-way trust relationship to Active Directory server and
use an Active Directory account to log in to a Red Hat Enterprise Linux server.

Log in to workstation as student using student as the password. Run the lab ad-trust
setup command to configure the environment.

[student@workstation ~]$ lab ad-trust setup

1. Change the DNS records for example.net domain. On the Active Directory
server, delegate the lab.example.net subdomain to the DNS running on the
idm.lab.example.net IdM server.
1.1. Log in to the Active Directory server as the Administrator user with
password123! as password.
1.2. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field, type cmd and wait for Windows to locate it.
1.3. On the Best match list, right-click the Command Prompt icon. From the displayed
menu, choose Run as administrator.
1.4. In the Administrator: Command Prompt window, type in the command to add an A
record and a NS record for the IdM domain:

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net idm.lab.example.net. ^
More? A 172.25.250.8

Add A Record for idm.lab.example.net at example.net

Command completed successfully.

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net ^
More? lab.example.net. NS ^
More? idm.lab.example.net.

Add NS Record for lab.example.net at example.net

Command completed successfully.

RH362-RHEL-7.4-en-1-20181003 209
CHAPTER 5 | Integrating IdM with Active Directory

2. Make sure that the Active Directory server properly resolves the SRV records for both
example.net and lab.example.net domains.
2.1. In the Administrator: Command Prompt window, execute the nslookup command.

C:\Users\administrator>nslookup
DNS request timed out.
timeout was 2 seconds.
Default Server: UnKnown
Address: ::1

2.2. Set the query type to srv and resolve _ldap._tcp records for both domains:

> set type=srv

> _ldap._tcp.example.net
...output omitted...
_ldap._tcp.example.net SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = ad.example.net
ad.example.net internet address = 172.25.250.13
> _ldap._tcp.lab.example.net
...output omitted...
_ldap._tcp.lab.example.net SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = idm.lab.example.net
idm.lab.example.net internet address = 172.25.250.8

2.3. Type exit to quit the nslookup command.

3. From workstation, open a new terminal and log in to the idm server as the student user,
then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

4. Install the ipa-server-trust-ad package.

[root@idm ~]# yum install ipa-server-trust-ad

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

5. Run the kinit admin command to log in to the IPA server. When prompted, use
RedHat123^ as password.

[root@idm ~]# kinit admin

210 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Password for admin@LAB.EXAMPLE.NET: RedHat123^

6. Use the ipa-adtrust-install command to set up components needed to establish

trust to Active Directory.

[root@idm ~]# ipa-adtrust-install --netbios-name=LABEXAMPLE -a RedHat123^

6.1. When the warning about the existing smb.conf file appears, type yes to continue.

NOTE
The warning and subsequent prompt only appears if the smb.conf file already
exists.

The log file for this installation can be found in /var/log/ipaserver-install.log

==============================================================================
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
* Configure Samba
* Add trust related objects to IPA LDAP server

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

WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your
existing samba configuration.

Do you wish to continue? [no]: yes

6.2. Type yes to enable trusted domains support in slapi-nis.

...output omitted...
Enable trusted domains support in slapi-nis? [no]: yes

6.3. Type yes to run the ipa-sidgen task.

...output omitted...
Do you want to run the ipa-sidgen task? [no]: yes

7. Change the IdM's DNS and search domain options.

[root@idm ~]# nmcli con mod "System eth0" ipv4.dns 127.0.0.1

[root@idm ~]# nmcli con mod "System eth0" ipv4.dns-search "lab.example.net"
[root@idm ~]# nmcli conn up "System eth0"
Connection successfully activated (D-Bus active path: /org/freedesktop/
NetworkManager/ActiveConnection/10)

RH362-RHEL-7.4-en-1-20181003 211
CHAPTER 5 | Integrating IdM with Active Directory

8. Edit the /etc/named.conf file and disable dnssec validation:

[root@idm ~]# vim /etc/named.conf

...output omitted...
dnssec-validation no;
...output omitted...

9. Restart IdM services using the ipactl restart command.

[root@idm ~]# ipactl restart

... output omitted ...
ipa: INFO: The ipactl command was successful

10. Use ipa dnsforwardzone-add command to add a DNS forwarder for the example.net
domain. To avoid external DNS queries for the example.net domain add the --skip-
overlap-check option.

[root@idm ~]# ipa dnsforwardzone-add \

--skip-overlap-check example.net \
--forwarder=172.25.250.13 \
--forward-policy=only
Server will check DNS forwarder(s).
This may take some time, please wait ...
Zone name: example.net.
Active zone: TRUE
Zone forwarders: 172.25.250.13
Forward policy: only

11. To apply the new DNS configuration, restart the named-pkcs11 on the IdM server.

[root@idm ~]# systemctl restart named-pkcs11

12. Use the dig command to verify that the IdM server properly resolves the SRV records for
the lab.example.net domain.

[root@idm ~]# dig SRV _ldap._tcp.lab.example.net

...output omitted...

;; ANSWER SECTION:
_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 idm.lab.example.net.

;; AUTHORITY SECTION:
lab.example.net. 86400 IN NS idm.lab.example.net.

;; ADDITIONAL SECTION:
idm.lab.example.net. 1200 IN A 172.25.250.8

...output omitted...

212 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

13. Use the dig command to verify that the IdM server properly resolves the SRV records for
the example.net domain.

[root@idm ~]# dig SRV _ldap._tcp.example.net

...output omitted...

;_ldap._tcp.example.net. IN SRV

;; ANSWER SECTION:
_ldap._tcp.example.net. 600 IN SRV 0 100 389 ad.example.net.

;; ADDITIONAL SECTION:
ad.example.net. 3600 IN A 172.25.250.13

...output omitted...

14. Use the ipa trust-add to create the one-way trust relationship with example.net
Active Directory domain. When prompted, enter password123! as the AD Administrator
password. After running the command, a new tab, Trusts is added in the IdM web console
under IPA Server.

[root@idm ~]# ipa trust-add --type=ad example.net --admin Administrator --password

Active Directory domain administrator's password: password123!

----------------------------------------------------
Added Active Directory trust for realm "example.net"
----------------------------------------------------
Realm name: example.net
Domain NetBIOS name: ADEXAMPLE
Domain Security Identifier: S-1-5-21-3950909341-3028684245-1018452525
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Established and verified

15. On the IdM server, verify that the one-way trust is working.
15.1. Use the kinit command to request a Kerberos ticket for the Active Directory
aduser01 user. When prompted, enter RedHat123^ as password.

[root@idm ~]# kinit aduser01@example.net

Password for aduser01@example.net: RedHat123^

15.2. The kvno command can be used to acquire a service ticket and print out the key
version number. Use kvno to request a Kerberos ticket for a service within the IdM
domain:

[root@idm ~]# kvno -S host idm.lab.example.net

host/idm.lab.example.net@LAB.EXAMPLE.NET: kvno = 2

15.3. Use the kvno command to request a Kerberos ticket for a service within the Active
Directory domain:

[root@idm ~]# kvno -S host ad.example.net

RH362-RHEL-7.4-en-1-20181003 213
CHAPTER 5 | Integrating IdM with Active Directory

host/ad.example.net@: kvno = 3

15.4. Use the klist command to ensure that the Kerberos tickets were successfully
granted.

[root@idm ~]# klist

Ticket cache: KEYRING:persistent:0:krb_ccache_fUDc0i7
Default principal: aduser01@EXAMPLE.NET

Valid starting Expires Service principal

03/22/2018 05:50:46 03/22/2018 15:50:33 host/ad.example.net@EXAMPLE.NET
renew until 03/23/2018 05:50:30
03/22/2018 05:50:46 03/22/2018 15:50:33 host/ad.example.net@
renew until 03/23/2018 05:50:30
03/22/2018 05:50:39 03/22/2018 15:50:33 host/idm.lab.example.net@LAB.EXAMPLE.NET
renew until 03/23/2018 05:50:30
03/22/2018 05:50:39 03/22/2018 15:50:33 krbtgt/LAB.EXAMPLE.NET@EXAMPLE.NET
renew until 03/23/2018 05:50:30
03/22/2018 05:50:33 03/22/2018 15:50:33 krbtgt/EXAMPLE.NET@EXAMPLE.NET
renew until 03/23/2018 05:50:30

NOTE
Notice that there is a cross-realm ticket-granting ticket (krbtgt) listed with the
other requested tickets. The other tickets on the list are the tickets for the different
services on the hosts in different domains.

16. From workstation, open a new terminal and log in to the client server as the
aduser05@example.net Active Directory user.

[student@workstation ~]$ ssh aduser05@example.net@client.lab.example.net

Could not chdir to home directory /home/example.net/aduser05: No such file or
directory
-sh-4.2$

17. To automatically create home directories for remote users, the oddjob-mkhomedir package
is required. For this exercise, the package is already installed. Switch identity to root and
enable home directory creation.

-sh-4.2$ su -
Password: redhat
[root@client ~]# authconfig --update --enablemkhomedir

NOTE
For this exercise, the package was already installed. However, for a newly
installed oddjob-mkhomedir package you must include --enablesssd --
enablesssdauth as additional options to the authconfig command.

18. Log out from the client.

214 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

19. From workstation, open a terminal and log in back to the client server as the
aduser05@example.net Active Directory user. This time, the home directory gets
created. Issue the pwd command to verify home directory creation.

[student@workstation ~]$ ssh aduser05@example.net@client.lab.example.net

Creating home directory for aduser05@example.net
-sh-4.2$ pwd
/home/example.net/aduser05

20. Log out from the client

21. Verify the Active Directory trust agreements.

21.1. Log in to the Active Directory server as user Administrator with password123!
as password. In the Server Manager dashboard, click the Tools drop-down menu.
21.2. From the list of available tools, click the Active Directory Domains and Trusts tool.
21.3. In the left pane, right-click the example.net domain and choose Properties.
21.4. In the example.net Properties window, click the Trusts tab.
21.5. In the lower pane, click the lab.example.net domain. With the lab.example.net
highlighted, click the Properties button.
21.6. In the lab.example.net Properties window, notice that the Trust type is Forest
and the direction of the trust is set to Incoming. This confirms that the trust was
created successfully, and that users from the Active Directory domain are allowed to
authenticate in the lab.example.net trusted domain.
21.7. Close all the opened windows and log out from the Active Directory server.

Cleanup
From workstation, run the lab ad-trust cleanup command to clean up this exercise.

[student@workstation ~]$ lab ad-trust cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 215
CHAPTER 5 | Integrating IdM with Active Directory

MANAGING ACTIVE DIRECTORY

INTEGRATION

OBJECTIVES
After completing this section, students should be able to:

• Describe the purpose of ID views.

• Describe the use of short and long names.

• Configure affinity.

INTRODUCING ID VIEWS
ID views enable administrators to specify new values for POSIX user or group attributes, as well
as to define on which client host or hosts the new values apply. Identity management systems
other than IdM typically generate user identifiers (UIDs) and group identifiers (GIDs) based on a
different algorithm than the one that IdM uses. Using ID views, IdM is able to override the values for
clients that used to be members of other integration systems in order to make them compliant.

ID views provide the following benefits:

• Overriding Active Directory user attributes, such as POSIX Attributes or SSH login information.

• Migrating integration from synchronization-based to trust-based integration.

• Overriding user attributes on a per-host basis.

Active Directory Default Trust View

Default Trust View is the default ID view which is always applied to Active Directory users and
groups in trust-based setups. The Default Trust View is created automatically when you establish
trust using the ipa-adtrust-install utility. It cannot be deleted. You can define custom
POSIX attributes for Active Directory users and groups by using the Default Trust View. Doing so
overrides the values in Active Directory.

NOTE
The Default Trust View only accepts overrides for Active Directory users and groups,
but not for IdM users and groups. It is set up on the IdM server and clients, and only
needs to provide overrides for Active Directory users and groups.

If another ID view that gets applied to the host overrides the attribute values in the Default Trust
View, then IdM applies the values from the host-specific ID view on top of the Default Trust View.
If an attribute is defined in the host-specific ID view, IdM applies the value from this view, but if an
attribute is not defined in the host-specific ID view, then IdM applies the value from the Default
Trust View. The Default Trust View is always applied to IdM servers and replicas, as well as to
Active Directory users and groups. You cannot assign a different ID view to the users and groups;
they always inherit the values of the Default Trust View.

IdM always overrides ID from the Default Trust View, regardless of how IdM clients retrieve the
values (from SSSD or using schema-compatibility tree requests). On Red Hat Enterprise Linux 7.1
and later, host-specific ID views are fully supported, but it is not supported for clients on Red Hat
Enterprise Linux 6.4 to 7.0.

216 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

On Red Hat Enterprise Linux 6.3 and earlier, clients can request a specific ID
view to be applied. To do so, change the base distinguished name on the client to
cn=id_view_name,cn=views,cn=compat,dc=example,dc=com.

NOTE
IdM uses ID ranges to avoid collisions of POSIX IDs from different domains. POSIX
IDs in ID views do not use a special range type, as IdM must allow overlaps with
other kinds of ID ranges (for example, Active Directory users created through
synchronization have IDs from the same ID range as IdM users). If an ID collision
occurs, fix it by changing the conflicting IDs in IdM.

Using ID Views To Deﬁne Active Directory User Attributes

With ID views, you can change the user attribute values defined in Active Directory. For example,
in a heterogeneous environment comprised of Linux and Microsoft Windows server, use ID views
to overrides attributes values. You can use ID views even if there is an Active Directory policy
preventing the usage of attributes. When Active Directory users authenticate to clients running
SSSD or authenticates using a compat LDAP tree, the new values are used in the authentication
process.

The following list describes the user attributes that an ID view can override:

• Login name (uid)

• GECOS entry (gecos)
• UID number (uidNumber)
• GID number (gidNumber)
• Login shell (loginShell)
• Home directory (homeDirectory)
• SSH public keys (ipaSshPubkey)
• Certificate (userCertificate)

The following list describes the group attributes that an ID view can override:

• Group name (cn)

• Group GID number (gidNumber)

IMPORTANT
Only IdM users can manage ID views. Active Directory users cannot.

Overriding attribute values is a three-step process:

1. Create a new ID view.

2. Add a user ID override in the ID view, and specify the required attribute value.

3. Apply the ID view to a specific host.

Using the Web Console to Manage ID Views

Log in to your IdM web console and navigate to Identity → ID Views to manage ID views. From
there, the Default Trust View view is the only view available. Click the Add button to create a new
ID view, then give it a name and a description. After creating a view, it can be edited.

The following screenshot shows the window for creating an ID view.

RH362-RHEL-7.4-en-1-20181003 217
CHAPTER 5 | Integrating IdM with Active Directory

Figure 5.5: Creating a custom ID view

You can override the following attributes with an ID view from the web console:

• The user to override

• The user login

• GECOS, user UID, and GID

• The user certificate

• The login shell and the home directory

The following screenshot shows the available options for when adding a user ID override. The
screen is only available after an ID view has been created and selected. Click the User tab and click
Add to override user settings.

218 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Figure 5.6: Overriding user attributes with ID views

NOTE
You can also create ID views for groups. However, settings are limited to the group
name and the GID.

Upon creation of the ID view, select the hosts that inherit the ID view, as shown in the following
screenshot.

RH362-RHEL-7.4-en-1-20181003 219
CHAPTER 5 | Integrating IdM with Active Directory

Figure 5.7: Assigning ID views to hosts

USING SHORT NAMES TO RESOLVE AND

AUTHENTICATE USERS AND GROUPS
You can use short user names or groups names for resolution and authentication in Active
Directory instead of the user@domain or domain\user notation. The short name notation, which
strips the domain of the user, is supported in an IdM environment that trusts Active Directory, or
on Red Hat Enterprise Linux servers that are members of Active Directory using SSSD.

Use the ipa config-mod utility with the --domain-resolution-order option to set
the domain resolution order to all clients in the trust. Doing this enables the short name
notation. For example, short name notation substitutes a user from Active Directory with
the login of aduser05@example.net with just aduser05. When using ssh to log in to
a client, ssh aduser05@example.net@client.lab.example.net becomes ssh
aduser05@client.lab.example.net.

IMPORTANT
You must use qualified names if a user name exists in multiple domains or if the
SSSD configuration includes the default_domain_suffix option and you want
to query a domain that is not specified with the option.

Red Hat recommends applying the domain resolution both globally and for an ID view. Clients
consult location in the following three places, and only the domain resolution order that is found
first is used:

1. The local sssd.conf configuration file

2. The ID view configuration
3. The global IdM configuration

NOTE
You can only set domain resolution order on a client in environments in which Red
Hat Enterprise Linux is directly integrated into an Active Directory environment.

220 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

To specify the order in which a list of domains is searched to return a match for a given user name,
use the domain_resolution_order option in the [sssd] section of the /etc/sssd/sssd.conf
configuration file:

[sssd]
...output omitted...
domain_resolution_order = subdomain1.ad.example.net, subdomain2.ad.example.net

Setting Domain Resolution Order Globally on IdM

Configure domain resolution order globally to set the domain resolution order to all clients in the
trust. To do so, use the ipa config-mod utility. The following screen shows how to configure
the domain resolution order in an IdM domain that trusts an Active Directory forest with multiple
subdomains. With this order, users from both the IdM domain and from the trusted Active Directory
forest can log in using short names.

NOTE
Notice the notation which separating each domain or subdomain by a colon.

[root@demo ~]$ ipa config-mod --domain-resolution-order=' \

idm.example.net \
:ad.example.net \
:domain1.ad.example.net \
:domainX.ad.example.net'
Maximum username length: 32
Home directory base: /home
...output omitted...
Domain Resolution Order: \
idm.example.net \
:ad.example.net \
:domain1.ad.example.net \
:domainX.ad.example.net
...output omitted...

Setting Domain Resolution Order for an ID View on IdM

Use this option to apply the setting to the clients in a specific domain. The following screen shows
how to configure the domain resolution order for a specific view.

[root@demo ~]$ ipa idview-add custom-view \

--desc "ID View for Custom Short Name Resolution" \
--domain-resolution-order \
subdomain2.ad.example.net
:subdomain1.ad.example.net
---------------------------------
Added ID View "custom-view"
---------------------------------
ID View Name: custom
Description: ID View for Custom Short Name Resolution
Domain Resolution Order: subdomain2.ad.example.com \
:subdomain1.ad.example.com

[root@demo ~]$ ipa idview-apply custom-view \

RH362-RHEL-7.4-en-1-20181003 221
CHAPTER 5 | Integrating IdM with Active Directory

--hosts server.idm.example.net
-----------------------------------
Applied ID View "custom-view"
-----------------------------------
hosts: server.idm.example.net
---------------------------------------------
Number of hosts the ID View was applied to: 1
---------------------------------------------

MANAGING DNS TIMEOUTS AND DNS LOCATIONS

In large deployments with DNS servers over WAN connections, clients may experience latency or
could be unable to resolve DNS names in a timely fashion. To decrease latency and optimize overall
DNS performance, you can configure SSSD clients to handle longer waiting time, and manage
DNS locations, which is a process by which the client uses the DNS protocol to locate servers in a
specified network.

Conﬁguring DNS Timeout and Time to Live

When an IdM server is configured as a client to an Active Directory server, it is fully capable of
discovering the Active Directory server on its own. Under certain conditions, such as a slow
network connection, clients may timeout if they are unable to reach the Active Directory server
within the first six seconds of the lookup.

The six second timeout is the default behavior and can be changed by increasing the value of the
dns_resolver_timeout setting in the sssd.conf file. The timeout value defines the amount of
time, in seconds, to wait for a reply from the DNS resolver before considering it unreachable. If the
value of the timeout is reached, then the domain continues to operate in offline mode.

Clients can cache DNS resource records for an amount of time that is set in the zone's
configuration. Because of this caching, a client might not be able to receive the changes until the
time to live (TTL) value is expired. The default TTL value in IdM is one day, but if the clients roam,
you should adapt the TTL values for the DNS zone. Doing so ensures that cached DNS entries on
the client expire before they reconnect to another site and query the DNS server to refresh SRV
records for locations.

You can also configure clients to prefer local servers over servers over WAN by configuring the
DNS resolution affinity. Add the various Kerberos servers in the [realms] section of the /etc/
krbd5.conf configuration file:

example.net {
kdc = kdc1.lab.example.net
kdc = kdc2.lab.example.net
...output omitted...
}

DNS Locations
You can configure DNS-based service discovery in IdM, a process by which a client uses DNS to
locate servers in networks which offer a specific service, such as Kerberos or LDAP. By configuring
DNS-based service discovery, clients can locate authentication servers within the closest network
infrastructure, as they provide a higher throughput and lower network latency.

By using service discovery, you do not need to explicitly configure clients with the name of nearby
servers. Moreover, DNS servers become the central providers of policy. That is, clients using the
same DNS server have access to the same policy about service providers and their preferred order.

222 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

In an IdM domain, the DNS service records, SRV records, exists for LDAP, Kerberos, and other
services.

The following command queries the DNS server for hosts providing a TCP-based Kerberos service
in an IdM DNS domain:

[root@demo ~]$ dig -t SRV +short \

_kerberos._tcp.idm.lab.example.net

0 100 88 idmserver-01.idm.lab.example.net.
0 100 88 idmserver-02.idm.lab.example.net.

The priority of the target host; a lower value is preferred

Specifies a relative weight for entries with the same priority
Prints the port number of the service
The canonical name of the host that provides the service

In the previous output, the two host names returned have the same priority and weight. In this
case, the client uses a random entry from the result list. When the client queries a DNS server
configured in a DNS location, the output differs: custom values are returned for IdM servers that
are assigned to a location.

In the following example, the client queries a DNS server in the location europe. The
IdM DNS server automatically returns a DNS alias (CNAME) pointing to the SRV records
of DNS locations. The CNAME record is displayed in the first line of the output, and the
idmserver-01.idm.lab.example.net host has the lowest priority value and is therefore
preferred. The idmserver-02.idm.lab.example.net has a higher priority and is used only as
a backup for cases when the preferred host is unavailable.

[root@demo ~]$ dig -t SRV +short \

_kerberos._tcp.idm.lab.example.net
_kerberos._tcp.europe._locations.idm.example.com.
0 100 88 idmserver-01.idm.lab.example.net.
50 100 88 idmserver-02.idm.lab.example.net.

For IdM DNS servers that are authoritative to the primary IdM DNS domain, IdM can generate
location-specific SRV records. Because each IdM DNS server generates location-specific SRV
records, you have to install at least one IdM DNS server in each DNS location.

NOTE
You can combine IdM DNS servers with non-IdM DNS slave servers only if the clients
doing DNS service discovery resolve location-specific records from IdM DNS servers.

In deployments with mixed IdM and non-IdM DNS services, recursive DNS servers select the
closest IdM DNS server automatically by using time-based round-trips. This process ensures that
clients using non-IdM DNS servers get records for the nearest DNS location. Consult the section
on Adding Additional Configuration for Master DNS Zones in the Red Hat Enterprise Linux 7 Domain
Identity, Authentication, and Policy Guide listed in the references section for more information.

The following procedure describes the required steps for creating and allocating DNS locations in
IdM:

1. Run the ipa location-add location to define a location.

RH362-RHEL-7.4-en-1-20181003 223
CHAPTER 5 | Integrating IdM with Active Directory

[root@demo ~]$ ipa location-add europe

2. Run the ipa location-find to list all available locations.

[root@demo ~]$ ipa location-find

3. Assign an IdM server to the DNS location.

[root@demo ~]$ ipa server-mod \

idmserver-01.idm.lab.example.net \
--location=europe
ipa: WARNING: Service named-pkcs11.service requires restart on IPA server
idmserver-01.idm.lab.example.net to apply configuration changes.
------------------------------------------------------
Modified IPA server "idmserver-01.idm.lab.example.net"
------------------------------------------------------
...output omitted...

4. Restart the named-pkcs11 service on the host.

[root@demo ~]$ systemctl restart named-pkcs11

SYNCHRONIZING ACTIVE DIRECTORY AND IDM USERS

If there is no trust between Active Directory and IdM, you can use synchronization to combine
user data stored in an Active Directory domain and the user data stored in the IdM domain.
Synchronization is the process of copying user data back and forth between Active Directory
servers and IdM servers. When users are synchronized between Active Directory and IdM, the
directory synchronization (DirSync) LDAP server extension control is used to search a directory
for objects that have changed.

NOTE
In the trust-based approach, authentication happens when the user entry and its
password are stored, which is the opposite behavior than a solution relying on
synchronization.

Critical user attributes, such as credentials, are copied and synchronized between the services.
Synchronization is performed through a process similar to replication, which uses hooks to connect
to a Windows server and retrieve directory data from the server. Password synchronization is
performed through a Windows service installed on Windows servers, which communicates to an
IdM server.

Synchronization is defined in an agreement between an IdM server and an Active Directory domain
controller. The agreement defines all of the information for identifying user entries that can be
synchronized, such as which subtree to synchronize, as well how account attributes are handled.
Synchronization agreements are created with default values, which can be adjusted to meet the
needs of a specific domain. When two servers are involved in synchronization, the servers are
called peers.

The following graphic describes the synchronization process between an IdM server and an Active
Directory server.

224 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

Figure 5.8: Synchronization process between IdM and Active Directory

Synchronization is bidirectional by default. Information is sent back and forth between the IdM
server and the Windows server in a process that is similar to how IdM servers and replicas share
information between themselves. However, new user entries are only added from the Windows
domain to the IdM domain. You can configure synchronization to only synchronize one way, which
is a process called unidirectional synchronization.

To mitigate the risk of having conflicting data, only one directory should originate or remove user
entries. If the Active Directory server is the primary identity manager in the organization, then
the server should be used as the authority for synchronization. In this scenario, new accounts or
account deletions are synchronized to the IdM server, even if both identity servers can modify
entries. Synchronization is configured between one IdM server and one Active Directory domain
controller: the IdM server propagates changes to the IdM domain, whereas the domain controller
propagates changes throughout the Windows domain.

The following diagram describes a synchronization topology comprised of an IdM server and a
Windows domain.

Figure 5.9: Synchronization topology

RH362-RHEL-7.4-en-1-20181003 225
CHAPTER 5 | Integrating IdM with Active Directory

NOTE
Set the winSyncInterval attribute in the Active Directory peers DN to modify the
frequency of the synchronization process. The entry shown has been formatted for
readability and should not contain carriage returns:

cn=meTowinserver.ad.example.com,
cn=replica,cn=dc\3Didm\,cn=dc\3Dlab\,
dc\3Dexample\,dc\3Dcom,
cn=mapping tree,cn=config

IMPORTANT
Some of the data in synchronization can be modified as part of the synchronization
process. For example, certain attributes can be automatically added to Active
Directory user accounts when they are synced with the IdM domain. These
attribute changes are defined as part of the synchronization agreement. For more
information, consult the section on Changing the Behavior for Synchronizing User
Account Attributes listed in the references section.

Setting Up Active Directory For Synchronization

To synchronize user accounts in IdM, you must set up a synchronization agreement, as defined
later in this section. However, you do not need to configure Active Directory servers. You only need
to create the user that is used by the IdM server to enable synchronization on Windows server. The
new user account must have proper permissions, as defined in the following list:

• Grant the synchronization user account Replicating directory changes rights to the
synchronized Active Directory subtree.

The synchronization user needs the Replicator privileges to perform synchronization

operations.

• Add the synchronization user as a member of the Account Operators and Enterprise
Read-only Domain Controllers groups. The user does not have to belong to the Domain
Admins group.

IMPORTANT
The IdM server connects to the Active Directory server using a secure connection.
You must configure a proper CA certificate in the Active Directory server, which can
be imported into the IdM security database.

Managing Password Synchronization

Synchronizing user entries is configured with synchronization agreements. However, passwords
in both Active Directory and IdM servers are not part of the regular user synchronization process.
A separate client must be installed on the Active Directory servers to capture passwords as user
accounts are created or passwords are changed, and then to forward that password information
with the synchronized updates.

226 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

IMPORTANT
The password synchronization client captures password changes and then
synchronizes them between the Active Directory server and the IdM server. This
means that it synchronizes new passwords or password updates.

Existing passwords are stored in a hashed form in both IdM and Active Directory.
They cannot be decrypted or synchronized when the password synchronization
client is installed, so existing passwords are not synchronized. User passwords must
be changed to initiate synchronization between the peer servers.

You require the following to synchronize passwords:

• Active Directory must be using SSL.

• The password synchronization service (PassSync) must be installed on each Active Directory
domain controller. To synchronize a password from Windows, the PassSync service requires
access to the unencrypted password to synchronize it over a secure connection to IdM.

• The password policy must be similar on IdM and Active Directory side. When the synchronization
destination receives an updated password, it is only validated to match the policy on the source,
but it is re-validated on the synchronization destination.

The following procedure describes the required steps to set up password synchronization on the
Active Directory server:

1. From your Microsoft customer portal, select the most recent version of Red Hat Enterprise
Linux 6 or Red Hat Enterprise Linux 7 and click the PassSync Installer link to your Active
Directory server.

2. Fill in the information to establish the connection to the IdM server, which includes:

• The IdM server connection information.

• The user name of the system user which Active Directory uses to
connect to the IdM server. This account is configured automatically when
synchronization is configured on the IdM server. The default account is
uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com.

• The password set in the --passsync option when the synchronization agreement was
created.

• The search base for the people subtree on the IdM server. The Active Directory server
connects to the IdM server similar to an ldapsearch or replication operation. The user
subtree is cn=users,cn=accoers,cn=accounts,dc=example,dc=com.

RH362-RHEL-7.4-en-1-20181003 227
CHAPTER 5 | Integrating IdM with Active Directory

Figure 5.10: The Red Hat directory password synchronization utility

3. Import the IdM server's CA certificate into the password synchronization certificate store by
downloading the IdM server's CA certificate from http://ipa.lab.example.net/ipa/config/ca.crt.
Copy the IdM CA certificate to the Active Directory server.

4. Install the IdM CA certificate in the password synchronization database:

cd "C:\Program Files\Red Hat Directory Password Synchronization"

certutil.exe -d . -A -n "IPASERVER.lab.example.net IPA CA" \
-t CT,, -a -i ipaca.crt

5. Reboot the Windows server to initiate the password synchronization process.

IMPORTANT
The first attempt to synchronize passwords always fails because of the SSL
connection between the Directory Server and Active Directory synchronization
peers.

NOTE
The password synchronization client cannot synchronize passwords for members of
the IdM admin group in order to prevent password synchronization agents or low
level user administrators to change passwords of top-level administrators.

228 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

• Changing the Behavior for Synchronizing User Account Attributes

Further information is available in the Red Hat Enterprise Linux 7 Domain Identity,
Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#modifying-
dns-zones

• Adding Additional Configuration for Master DNS Zones

Further information is available in the chapter on Configuring SSSD in the Red Hat
Enterprise Linux 7 System-Level Authentication Guide at
https://access.redhat.com/documentation/en-US/index.html

sssd-ad(5) man page.

RH362-RHEL-7.4-en-1-20181003 229
CHAPTER 5 | Integrating IdM with Active Directory

GUIDED EXERCISE

MANAGING ACTIVE DIRECTORY

SETTINGS
In this exercise, you will create an ID view, configure short names for users, verify discovery
configuration, and remove the trust with Active Directory.

OUTCOMES
You should be able to create an ID view, configure short names for users, and remove the
existing trust with Active Directory.

Log in to workstation as student using student as the password. Run the lab ad-manage
setup command to configure the environment.

[student@workstation ~]$ lab ad-manage setup

1. On the client server, add a new users group with ID of 1111.

1.1. From workstation, open a new terminal and log in to the client server as the
student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

1.2. Use the groupadd command with -g 1111 adusers option, to add a new group
with ID of 1111 to the system.

[root@client ~]# groupadd -g 1111 adusers

2. On the client server, create a new home directory called aduser05_view and change
the owner of that directory.
2.1. Use mkdir /home/aduser05_view to create the new home directory.

[root@client ~]# mkdir /home/aduser05_view

2.2. Change the ownership of /home/aduser05_view directory to 1111:1111.

[root@client ~]# chown 1111:1111 /home/aduser05_view

2.3. Log out from the client server.

230 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

3. On the IdM server, create a new view called adview with a description of AD id view.
3.1. From workstation, open a new terminal and log in to the idm server as the
student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

3.2. Run the kinit admin command to authenticate and obtain Kerberos credentials.
When prompted, enter RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3.3. Use the ipa idview-add command to create a new view in the IdM domain.

[root@idm ~]# ipa idview-add --desc="AD id view" adview

-----------------------
Added ID View "adview"
-----------------------
ID View Name: adview
Description: AD id view

4. Within the adview view, create a new user attributes override view for the aduser05
Active Directory user.
As root user on the IdM server, use the ipa overrideuser-add command to create
a new view for the aduser05 user to override the attributes of that user stored in Active
Directory. Override the standard attributes with the /bin/bash shell, 1111 UID, 1111 GID
and /home/aduser05_view home directory.

[root@idm ~]# ipa idoverrideuser-add \

--desc="Overrides for aduser05" \
--shell=/bin/bash \
--homedir=/home/aduser05_view \
--uid=1111 --gidnumber=1111 \
adview aduser05@example.net
---------------------------------------------
Added User ID override "aduser05@example.net"
---------------------------------------------
Anchor to override: aduser05@example.net
Description: Overrides for aduser05
UID: 1111
GID: 1111
Home directory: /home/aduser05_view
Login shell: /bin/bash

5. Use the ipa idview-apply command to apply the new adview view to the client
server.

[root@idm ~]# ipa idview-apply --hosts=client.lab.example.net adview

-------------------------

RH362-RHEL-7.4-en-1-20181003 231
CHAPTER 5 | Integrating IdM with Active Directory

Applied ID View "adview"

-------------------------
hosts: client.lab.example.net
---------------------------------------------
Number of hosts the ID View was applied to: 1
---------------------------------------------

6. Log out from the IdM server.

7. Clear the SSSD cache and restart the SSSD service to enable the view on the client
server.
7.1. From workstation, open a new terminal and log in to the client server as the
student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

7.2. Use the sss_cache -E command to clean the SSSD cache.

[root@client ~]# sss_cache -E

7.3. Use systemctl restart sssd to restart the SSSD service.

[root@client ~]# systemctl restart sssd

7.4. Log out from the client server.

8. Test the new configuration by logging in to the client server as the aduser05 Active
Directory user.
8.1. From workstation, open a new terminal and log in to the
client.lab.example.net server as the aduser05 user.

[student@workstation ~]$ ssh aduser05@example.net@client.lab.example.net

-bash-4.2$

8.2. Verify the new view by issuing the id command followed by the pwd command.

-bash-4.2$ id
uid=1111(aduser05) gid=1111(adusers) groups=1111(adusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-bash-4.2$ pwd
/home/aduser05_view

NOTE
Notice that the user has the correct UID and GID, as well as the home directory. All
these user attributes were applied through the use of the new ID view on the IdM
server.

8.3. Log out from the client server.

232 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

9. Use short names to resolve and authenticate users from the Active Directory domain.
9.1. From workstation, open a new terminal and log in to the idm server as the
student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

9.2. Use the ipa config-mod command with the --domain-resolution-order

option to set the domain resolution order to all the clients in the trust.

[root@idm ~]# ipa config-mod \

--domain-resolution-order='lab.example.net:example.net'
Maximum username length: 32
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: lab.example.net
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: FALSE
Certificate Subject base: O=LAB.EXAMPLE.NET
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-
s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: idm.lab.example.net
IPA CA servers: idm.lab.example.net
IPA NTP servers: idm.lab.example.net
IPA CA renewal master: idm.lab.example.net
IPA master capable of PKINIT: idm.lab.example.net
Domain resolution order: lab.example.net:example.net

9.3. Log out from the IdM server.

10. Clear the SSSD cache and restart the SSSD service to enable the view on the client
server.
10.1. From workstation, open a new terminal and log in to the
client.lab.example.net server as the student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student

RH362-RHEL-7.4-en-1-20181003 233
CHAPTER 5 | Integrating IdM with Active Directory

[root@client ~]#

10.2. Use the sss_cache -E command to clean the SSSD cache.

[root@client ~]# sss_cache -E

10.3. Use the systemctl restart sssd command to restart the SSSD service.

[root@client ~]# systemctl restart sssd

10.4. Log out from the client server.

11. Verify that the new configuration is working as expected. Log in to the client server as the
aduser05 user without specifying the @example.net domain name.
11.1. From workstation, open a new terminal and log in to the
client.lab.example.net server as the aduser05 user.

[student@workstation ~]$ ssh aduser05@client.lab.example.net

-bash-4.2$

11.2. Use the id command to verify that the credentials used to authenticate the
aduser05 were taken from the example.net Active Directory domain.

-bash-4.2$ id
uid=1111(aduser05@example.net) gid=1111(adusers) groups=1111(adusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

NOTE
Notice that the new domain resolution configuration change allows users to log in
to the servers using shorter names. There is no need to specify the domain name
storing the user information.

11.3. Log out from the client server.

12. Verify the existing trust relationship to Active Directory.

From workstation, open a new terminal and log in to the idm server as the student user,
then become root. Use the ipa trustdomain-find example.net command to verify
that the trust has been created.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# ipa trustdomain-find example.net
Domain name: example.net
Domain NetBIOS name: ADEXAMPLE
Domain Security Identifier: S-1-5-21-3950909341-3028684245-1018452525
Domain enabled: True
----------------------------
Number of entries returned 1
----------------------------

234 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

13. Remove the trust relationship from both the IdM and the Active Directory server.
13.1. On workstation open a terminal and log in to the idm.lab.example.net server
as the root user. On the idm.lab.example.net server, use the ipa trust-del
example.net command to remove the trust.

[root@idm ~]# ipa trust-del example.net

---------------------------
Deleted trust "example.net"
---------------------------

13.2. Log in to the Active Directory server as the Administrator user with
password123! as password.
13.3. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field type cmd and wait for Windows to locate it.
13.4. On the Best match list, right-click the Command Prompt icon. From the displayed
menu, choose Run as administrator.
13.5. In the Administrator: Command Prompt window, type in the command to remove the
existing trust with lab.example.net domain:

C:\Users\administrator>netdom trust lab.example.net ^

More? /d:example.net /remove ^
More? /UserD:administrator /PasswordD:password123! ^
More? /FORCE
The command completed successfully.

14. Remove all DNS records that are required on both ends of the trust.
14.1. On the idm.lab.example.net server, use the ipa dnsforwardzone-del
example.net command to remove the DNS forward zone.

[root@idm ~]# ipa dnsforwardzone-del example.net

---------------------------------------
Deleted DNS forward zone "example.net."
---------------------------------------

14.2. Log in to the Active Directory server as the Administrator user with
password123! as password.
14.3. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field, type cmd and let Windows find it.
14.4. On the Best match list, right-click the Command Prompt icon. From the displayed
menu, choose Run as administrator.
14.5. In the Administrator: Command Prompt window, type in the command to remove the
DNS domain delegation for lab.example.net domain:

C:\Users\administrator>dnscmd 127.0.0.1 ^
More? /RecordDelete example.net ^
More? lab.example.net. NS ^
More? idm.lab.example.net.
Are you sure you want to delete record? (y/n) y

Deleted NS record(s) at example.net

RH362-RHEL-7.4-en-1-20181003 235
CHAPTER 5 | Integrating IdM with Active Directory

Command completed successfully.

14.6. Delete the A record pointing to idm.lab.example.net server.

C:\Users\administrator>dnscmd 127.0.0.1 ^
More? /RecordDelete example.net ^
More? idm.lab.example.net. A ^
More? 172.25.250.8
Are you sure you want to delete record? (y/n) y

Deleted NS record(s) at example.net

Command completed successfully.

15. Verify that the trust has been removed.

15.1. From workstation, open a new terminal and log in to the client server as the
student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

15.2. Restart the SSSD service.

[root@client ~]# systemctl restart sssd

15.3. Log out from the client.lab.example.net server. To verify that the trust no
longer works, try logging back in as the aduser05@example.net Active Directory
user. When prompted, enter Redhat123 as the password.

NOTE
The operation should fail, which confirms that the trust has been successfully
removed.

[student@workstation ~]$ ssh aduser05@example.net@client.lab.example.net

Password: RedHat123^
Password: RedHat123^

Cleanup
From workstation, run the lab ad-manage cleanup command to clean up this exercise.

[student@workstation ~]$ lab ad-manage cleanup

This concludes the guided exercise.

236 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

LAB

INTEGRATING IDM WITH ACTIVE

[student@workstation ~]$ lab ad-review setup

1. Delegate the lab.example.net subdomain from the Active Directory server to the
idm.lab.example.net IdM server.
2. On the IdM server, add a new DNS forward zone to example.net domain. Use the
ad.example.net server with the IP address of 172.25.250.13 as the forwarder.
3. Establish a new trust to Active Directory server in the example.net domain.
4. Verify that the aduser03 Active Directory user can log in to the client server.

Evaluation
From workstation, run the lab ad-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab ad-review grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 237
CHAPTER 5 | Integrating IdM with Active Directory

SOLUTION

INTEGRATING IDM WITH ACTIVE

[student@workstation ~]$ lab ad-review setup

1. Delegate the lab.example.net subdomain from the Active Directory server to the
idm.lab.example.net IdM server.
1.1. Log in to the Active Directory server as the Administrator user with
password123! as password.
1.2. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field, type cmd and wait for Windows to locate it.
1.3. On the Best match list, right-click the Command Prompt icon. From the displayed
menu, choose Run as administrator.
1.4. In the Administrator: Command Prompt window, type in the command to add an A
record and an NS record for the IdM domain:

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net idm.lab.example.net. ^
More? A 172.25.250.8

Add A Record for idm.lab.example.net at example.net

Command completed successfully.

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net ^
More? lab.example.net. NS ^
More? idm.lab.example.net.

Add NS Record for lab.example.net at example.net

Command completed successfully.

2. On the IdM server, add a new DNS forward zone to example.net domain. Use the
ad.example.net server with the IP address of 172.25.250.13 as the forwarder.

238 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

2.1. From workstation, open a new terminal and log in to the idm server as the student
user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

2.2. Run the kinit admin command to authenticate and obtain Kerberos credentials.
When prompted, enter RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

2.3. On the IdM server, use the ipa dnsforwardzone-add command to add a DNS
forwarder for the example.net domain. To avoid external DNS queries for the
example.net domain add the --skip-overlap-check option.

[root@idm ~]# ipa dnsforwardzone-add --skip-overlap-check example.net \

--forwarder=172.25.250.13 \
--forward-policy=only

2.4. Restart the named-pkcs11 service on the IdM server.

[root@idm ~]# systemctl restart named-pkcs11

3. Establish a new trust to Active Directory server in the example.net domain.

On IdM server, use the ipa trust-add command to create the one-way trust relationship
with example.net Active Directory domain. When prompted, enter password123! as the
AD Administrator password.

[root@idm ~]# ipa trust-add --type=ad example.net --admin Administrator --password

Active Directory domain administrator's password: password123!
----------------------------------------------------
Added Active Directory trust for realm "example.net"
----------------------------------------------------
Realm name: example.net
Domain NetBIOS name: ADEXAMPLE
Domain Security Identifier: S-1-5-21-3950909341-3028684245-1018452525
Trust direction: Trusting forest
Trust type: Active Directory domain
Trust status: Established and verified

4. Verify that the aduser03 Active Directory user can log in to the client server.
4.1. From workstation, open a new terminal and log in to the client server as the
student user, then become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student

RH362-RHEL-7.4-en-1-20181003 239
CHAPTER 5 | Integrating IdM with Active Directory

[root@client ~]#

4.2. Use the systemctl stop sssd command to stop SSSD.

[root@client ~]# systemctl stop sssd

4.3. Use the rm -rf /var/lib/sss/db/* command to remove all SSSD cached files.

[root@client ~]# rm -rf /var/lib/sss/db/*

4.4. Use the systemctl start sssd command to start the SSSD service.

[root@client ~]# systemctl start sssd

4.5. Log out from the client server.

4.6. From workstation, log in to the client.lab.example.net server as the
aduser03@example.net Active Directory user and exit the server.

[student@workstation ~]$ ssh aduser03@example.net@client.lab.example.net

-sh-4.2$ exit
[student@workstation ~]$

Evaluation
From workstation, run the lab ad-review grade command to confirm the success of this
exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab ad-review grade

This concludes the lab.

240 RH362-RHEL-7.4-en-1-20181003
CHAPTER 5 | Integrating IdM with Active Directory

SUMMARY

In this chapter, you learned:

• There are two methods to integrate Linux hosts with Active Directory: direct and indirect. Using
the direct method, Linux clients are configured as part of the Active Directory domain using
native Linux tools and protocols. In the indirect method, Linux clients are members of an IdM
domain which has a trust relationship established with Active Directory. The indirect method
is preferred due to the management features of IdM, such as sudo integration, certificate
management, automount, and HBAC policies.

• Trust relationships between Active Directory and IdM can be one-way or bidirectional. In the
default one-way trust, IdM trusts users from Active Directory. This means that AD users can
access resources in the IdM domain. When a trust relationship between IdM and AD is created,
there must be at least one trust controller to manage the trust relationship. All other IdM servers
that are serving AD users must be configured as trust agents.

• ID views allow foreign UIDs, GIDs, or other attributes to be remapped in IdM to avoid ID conflicts.
They can be remapped at a global or host level, where an attribute set in a host ID view overrides
the global ID view setting. If an attribute is not overridden in a host ID view, the global setting
takes effect. To simplify user logins, domain resolution order can be configured, allowing users
to provide short names rather than their UserPrincipalName (UPN). Domain resolution order can
be configured globally or as an ID view. To increase DNS performance, you can create locations
in IdM that can then have hosts added. When an IdM server is allocated to a location, it responds
to client requests for SRV records with weighted results. Specifically, local hosts providing the
requested service have a lower priority value and therefore are preferred. Synchronization
of user data between AD and IdM is an alternative to trust relationships, but is an invasive
configuration, as PassSync must be installed on every AD domain controller.

RH362-RHEL-7.4-en-1-20181003 241
242 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6

CONTROLLING USER ACCESS

GOAL Configuring users for authorized access to services
and resources.

OBJECTIVES • Configure user life-cycle parameters and

resources
• Configure user access rights using host-based
and sudo authorization policies
• Discuss configuring advanced authentication
mechanisms
• Configure policy management rules and
administration

SECTIONS • Managing User Identities (and Guided Exercise)

• Managing User Access (and Guided Exercise)
• Securing the Login Process (and Guided
Exercise)
• Managing IdM User Access Rules (and Guided
Exercise)

LAB Controlling User Access

RH362-RHEL-7.4-en-1-20181003 243
CHAPTER 6 | Controlling User Access

MANAGING USER IDENTITIES

OBJECTIVES
After completing this section, students should be able to:

• Configure account life-cycle parameters.

• Manage user SSH keys.

• Change and reset user passwords.

MANAGING USER ACCOUNTS

User account life-cycle management tasks, such as creating users and groups, are typically
performed by a system administrator. However, these tasks can be delegated to non-administrative
users by defining access controls.

Access controls define who can access certain resources such as machines or services and what
kinds of operations users are allowed to perform. Identity Management provides several access
control areas to make it clear what kind of access is being granted and to whom it is granted.
Additionally, IdM draws a distinction between access controls to resources within the domain and
access control to the IdM configuration itself.

To delegate specific administrative tasks to a non-administrative user, a Role-Based Access Control

(RBAC) can be defined and assigned to a special access control group that is granted edit, add, and
delete rights for user and group attributes.

Creating a Role Using the Command Line

The following steps outline the process for creating a role for allowing basic administrative tasks to
modify user account attributes.

1. Acquire Kerberos credentials for the admin user on the IdM server.

2. Add a new role using the ipa role-add command. Provide both a description and name for
the new role.

3. Use the ipa role-add-privilege command to add a privilege to allow user

administration of the new role. Provide both the User Administrators privilege and the
name of the new role from the previous step.

4. Add groups to the role containing the users who will administer user accounts. In this
example, the ipa role-add-member command adds a previously created group named
useradmins.

Conﬁguring Automatic Group Membership

You can assign users and hosts to groups automatically based on their attributes by using
automatic group membership.

Define automember rules to configure automatic group membership. An automember rule applies
to a specific user or host group and includes conditions that the user or host must meet to be
included or excluded from the group.

244 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Adding an Automember Rule

The following steps outline the process for creating a role for allowing basic administrative tasks to
modify user account attributes.

1. Use the ipa automember-add command to add an automember rule.

2. Define one or more inclusive and exclusive conditions.

MANAGING USER SSH PUBLIC KEYS

Identity Management allows you to upload a public SSH key to a user entry. The user who has
access to the corresponding private SSH key can use the ssh command to log into an IdM machine
without using Kerberos credentials. If the pam_krb5 module is configured properly, or if SSSD is
used as the IdM server's identity provider, the user also receives a Kerberos ticket-granting ticket
(TGT) after login.

Caching and Retrieving SSH Keys Automatically

During an IdM server or client installation, SSSD is automatically configured on the machine to
cache and retrieve user and host SSH keys. This allows IdM to serve as a universal and centralized
repository of SSH keys.

Generating an SSH Key

The following example generates an SSH key using the OpenSSH ssh-keygen utility:

[root@idmserver ~]# ssh-keygen -t rsa \

-C idmuser@lab.example.com
Generating public/private rsa key pair.
Enter file in which to save the key (/home/idmuser/.ssh/id_rsa):
Created directory '/home/idmuser/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/idmuser/.ssh/id_rsa.
Your public key has been saved in /home/idmuser/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GAUIDVVEgly7rs1lTWP6oguHz8BKvyZkpqCqVSsmi7c idmuser@example.com
The key's randomart image is:
+--[ RSA 2048]----+
| |
| + . |
| + = . |
| = + |
| . E S.. |
| . . .o |
| . . . oo. |
| . o . +.+o |
| o .o..o+o |
+-----------------+

Uploading User SSH Keys

The following step outline the process for using the command line to upload an SSH key to an IdM
server.

[root@idmserver ~]# ipa user-mod idmuser \

--sshpubkey="$(cat ~/.ssh/id_rsa.pub)"

RH362-RHEL-7.4-en-1-20181003 245
CHAPTER 6 | Controlling User Access

Caching and Retrieving SSH Keys Automatically

The System Security Services Daemon (SSSD) can serve as a credentials cache for SSH public keys
for servers and users. Only Linux machines in the IdM domain can use SSSD as a key cache for
OpenSSH. Other machines, including Windows servers, cannot.

• OpenSSH is configured to reference SSSD to check for cached keys.

• SSSD uses an IdM domain, and IdM stores the public keys and host information.

How SSSD Manages User Keys

SSSD performs the following steps to manage user keys:

1. Retrieves the user's public key from the user entries in the IdM domain.

2. Stores the user key in the .ssh/sss_authorized_keys file in the standard authorized keys
format.

CHANGING AND RESETTING USER PASSWORDS

Regular users without permission to change other users' passwords can change only their own
personal password and must adhere to IdM password policies. Administrators and users with
password change rights can set initial passwords for new users and reset passwords for existing
users and are not restricted by IdM password policies.

Changing Your Own User Password

The following steps show how to use the web UI to change a user's password as a regular user.

1. Log in to the IdM web UI using your IdM user account.

2. Navigate to the top right corner and select the User name → Change password menu choice.

3. In the Reset Password form, enter your password information.

4. To confirm the password change, click the Reset Password button.

Changing Another User's Password

The following steps show how to use the web UI to change another user's password.

1. Log in to the IdM web UI as the admin user or an account that has password change rights.

2. Navigate to the Identity → Users → Active users menu choice.

3. Click on the name of the user you want to edit.

4. Click the Actions → Reset Password menu choice.

5. In the Reset Password form, enter the password information.

6. To confirm the password change, click the Reset Password button.

REFERENCES
Further information is available in the Defining Access Control for IdM Users section
of the Red Hat Enterprise Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#server-
access-controls

246 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

GUIDED EXERCISE

MANAGING USER IDENTITIES

In this exercise, you will configure user life-cycle parameters and resources.

OUTCOMES
You should be able to:

• Create users with life-cycle parameters.

• Change user passwords.

• Configure user group membership.

Log in to workstation as student using student as the password. Run the lab users-
identities setup command to configure the environment.

[student@workstation ~]$ lab users-identities setup

1. Delegate user management to a regular user.

1.1. From workstation, open a terminal and use the ssh command to log in to the IdM
server as the student user, and then become root.

[student@workstation ~]$ ssh idm

Password: student
[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Run the kinit command to obtain a Kerberos ticket. When prompted, use
RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET:RedHat123^

1.3. Create the User Provisioning role by running the ipa command with the role-
add option. Give the role a description of Role for Provisioning Users.

[root@idm ~]# ipa role-add --desc "Role for Provisioning Users" \

"User Provisioning"
--------------------------------
Added role "User Provisioning"
--------------------------------
Role name: User Provisioning
Description: Role for Provisioning Users

1.4. Add the User Administrators privilege to the User Provisioning role by
running the ipa command with the role-add-privilege option. The privilege is
used for creating users.

RH362-RHEL-7.4-en-1-20181003 247
CHAPTER 6 | Controlling User Access

[root@idm ~]# ipa role-add-privilege "User Provisioning" \

--privileges="User Administrators"
Role name: User Provisioning
Description: Role for Provisioning Users
Privileges: User Administrators
----------------------------
Number of privileges added 1
----------------------------

1.5. Grant the idmuser01 user the privilege required for adding users by running the
ipa command with the role-add-member option.

[root@idm ~]# ipa role-add-member "User Provisioning" \

--users=idmuser01
Role name: User Provisioning
Description: Role for Provisioning Users
Member users: idmuser01
Privileges: User Administrators
-------------------------
Number of members added 1
-------------------------

1.6. Review the members of the role to ensure that the idmuser01 is a member of the
role.

[root@idm ~]# ipa role-show "User Provisioning"

Role name: User Provisioning
Description: Role for Provisioning Users
Member users: idmuser01
Privileges: User Administrators

2. Create a group and define a rule for automatic membership.

2.1. From the idm server, use the ipa command with the group-add option to create
the idmgroup05 group.

[root@idm ~]# ipa group-add idmgroup05 \

--desc "Auto Membership Group"
------------------------
Added group "idmgroup05"
------------------------
Group name: idmgroup05
Description: Auto Membership Group
GID: 1370600012

2.2. Define a password policy for the group. Set the password policy to require a
minimum of 8 characters, and to prevent further login attempts after two failures.
Make it the top policy if other password policies also pertain to this user.

[root@idm ~]# ipa pwpolicy-add idmgroup05 \

--minlength 8 --priority 1 --maxfail 2
Group: idmgroup05
Min length: 8
Priority: 1

248 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Max failures: 2

2.3. Create a new automatic group membership rule for the idmgroup05 group named
idmgroup05.

[root@idm ~]# ipa automember-add idmgroup05 \

--type="group" \
--desc="Auto Member Rule for idmgroup05"
----------------------------------
Added automember rule "idmgroup05"
----------------------------------
Automember Rule: idmgroup05
Description: Auto Member Rule for idmgroup05

2.4. Run the ipa command with the automember-add-condition option to define an
inclusive regular expression. The expression includes all users with a UID beginning
with idmuser.

[root@idm ~]# ipa automember-add-condition

Automember Rule: idmgroup05
Attribute Key: uid
Grouping Type: group
[Inclusive Regex]: idmuser.*
[Exclusive Regex]: [Enter]
----------------------------------
Added condition(s) to "idmgroup05"
----------------------------------
Automember Rule: idmgroup05
Description: Auto Member Rule for idmgroup05
Inclusive Regex: uid=idmuser.*
----------------------------
Number of conditions added 1
----------------------------

2.5. Run the ipa command with the automember-add-condition option to define an
inclusive regular expression that includes all users from Active Directory.

[root@idm ~]# ipa automember-add-condition

Automember Rule: idmgroup05
Attribute Key: objectclass
Grouping Type: group
[Inclusive Regex]: ntUser
[Exclusive Regex]: [Enter]
----------------------------------
Added condition(s) to "idmgroup05"
----------------------------------
Automember Rule: idmgroup05
Description: Auto Member Rule for idmgroup05
Inclusive Regex: uid=idmuser.*, objectclass=ntUser
----------------------------
Number of conditions added 1

RH362-RHEL-7.4-en-1-20181003 249
CHAPTER 6 | Controlling User Access

----------------------------

2.6. Rebuild user membership to ensure that users whose UID begins with idmuser are
automatically added to the idmgroup05 group.

[root@idm ~]# ipa automember-rebuild --type=group

--------------------------------------------------------
Automember rebuild task finished. Processed (6) entries.
--------------------------------------------------------

2.7. List the users in the idmgroup05 group. Ensure that IdM users have been
automatically added as members of the group.

NOTE
The output does not display Active Directory users, it only shows IdM users.

[root@idm ~]# ipa group-show idmgroup05

Group name: idmgroup05
Description: Auto Membership Group
GID: 1370600012
Member users: idmuser05, idmuser04, idmuser03, idmuser02, idmuser01

3. Manage user life-cycle settings.

3.1. From workstation, open Firefox and go to https://idm.lab.example.net.
Log in to the IdM web console using idmuser01 as the user name and RedHat123^
as the password.
3.2. Create a new user by navigating to Identity → Users → Active users. Click Add to
create a new user.
Create a user according to the following information. Leave all other fields
untouched.

FIELD VALUE

User login idmuser06

First name user06

Last name idm

New Password and Verify Password redhatexp

Click Add and Edit to create the user and access its properties.
3.3. Update the user shell by giving the Login shell field a value of /bin/bash.
3.4. Import the user public key by clicking Add for the SSH public keys entry. Copy the
full content of the idmuser06-key.pub file accessible on workstation at /
home/student/RH362/labs/users-identities/idmuser06-key.pub.
Paste the copied content into the SSH public key field on the SSH public keys popup
window. Do not modify the resulting pasted content, even though it appears to have
embedded linefeeds.
Click Set.
3.5. Click Save at the top of the page to update the user settings.
250 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

4. Confirm the life-cycle settings.

4.1. From workstation, open a new terminal and use the ssh command to log in to the
client VM as the idmuser06 user.
When prompted for a password, enter Ctrl+C to cancel the connection.

[student@workstation ~]$ ssh idmuser06@client

Password: Ctrl+C

4.2. From workstation, open a second terminal and use the ssh command to log in to
the idm VM as the student user, then become root. Ensure that the admin user
has valid Kerberos credentials.

[student@workstation ~]$ ssh idm

Password: student
[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

4.3. From tho idm VM, use the idm user-status command to verify that user
idmuser06 has not exceeded the max number of logins and that the account is
enabled. Failed logins should be less than 2 and Account disabled should
be set to False.

[root@idm ~]# ipa user-status idmuser06

-----------------------
Account disabled: False
-----------------------
Server: idm.lab.example.net
Failed logins: 0
Last successful authentication: N/A
Last failed authentication: 20180417035020Z
Time now: 2018-04-17T03:59:05Z
----------------------------
Number of entries returned 1
----------------------------

4.4. Rerun the ssh command to log in to the client VM as the idmuser06 user. Use
the private key located at /home/student/RH362/labs/users-identities/
idmuser06-key, which matches the public key imported for the user. Ensure that
the shell is bash and reset the user password. Enter a six-character password to
verify the password policy.

[student@workstation ~]$ ssh -i RH362/labs/users-identities/idmuser06-key \

idmuser06@client
[idmuser06@lab.example.net@client ~]$ env | grep -i shell
SHELL=/bin/bash
[idmuser06@lab.example.net@client ~]$ passwd
Changing password for user idmuser06@lab.example.net.
Current Password: redhatexp
New Password: fedora
Retype new password: fedora
Password change failed. Server message: Password is too short

RH362-RHEL-7.4-en-1-20181003 251
CHAPTER 6 | Controlling User Access

Password not changed.

passwd: Authentication token manipulation error

4.5. Rerun the passwd command and use an eight-character password as follows:

[idmuser06@lab.example.net@client ~]$ passwd

Changing password for user idmuser06@lab.example.net.
Current Password: redhatexp
New Password: redhatrst
Retype new password: redhatrst
passwd: all authentication tokens updated successfully.

4.6. Exit the client.

[idmuser06@lab.example.net@client ~]$ exit

[student@workstation ~]$

4.7. Log in to the IdM web console as idmuser01 using redhatrst as the password.
Disable the idmuser06 user by navigating to Identity → Users → Active Users.
Select the idmuser06 user and click Disable button. Click OK to confirm the action.
4.8. From the idm VM, use the idm user-status command to verify that user
idmuser06 has not exceeded the max number of logins but that the account is
disabled. Account disabled should be set to True and Failed logins should
be set to 0.

[root@idm ~]# ipa user-status idmuser06

-----------------------
Account disabled: True
-----------------------
Server: idm.lab.example.net
Failed logins: 0
Last successful authentication: N/A
Last failed authentication: 20180417043421Z
Time now: 2018-04-17T04:41:05Z
----------------------------
Number of entries returned 1
----------------------------

4.9. From workstation, attempt to log in to client as user idmuser06 using the
private key located at /home/student/RH362/labs/users-identities/
idmuser06-key. This attempt should fail.

[student@workstation ~]$ ssh -i RH362/labs/users-identities/idmuser06-key \

idmuser06@client
Authentication failed.

4.10. From workstation, try to log back in to the client as the user idmuser06 using
password authentication. Use redhatrst as the password. After several attempts at
entering a password, the authentication should fail. Although there are several failed
attempts to log in to the account the failed logins value does not increment because
the account is disabled.

[student@workstation ~]$ ssh idmuser06@client

Password: redhatrst

252 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Password: redhatrst
Password: redhatrst
idmuser06@client's password: redhatrst
Permission denied, please try again.
idmuser06@client's password: redhatrst
Permission denied, please try again.
idmuser06@client's password: redhatrst
Authentication failed.
[student@workstation ~]$

4.11. From the idm VM, use the idm user-status command to verify that the failed
logins value is still set to 0 and the user account remains disabled.

[root@idm ~]# ipa user-status idmuser06

-----------------------
Account disabled: True
-----------------------
Server: idm.lab.example.net
Failed logins: 0
Last successful authentication: N/A
Last failed authentication: 20180417043421Z
Time now: 2018-04-17T05:08:05Z
----------------------------
Number of entries returned 1
----------------------------

4.12. Log in to the IdM web console as idmuser01 using redhatrst as the password.
Enable the idmuser06 user by navigating to Identity → Users → Active Users
Select the idmuser06 user and click Enable button. Click OK to confirm the action.
4.13. Verify that you can log in to the client as the user idmuser06 using SSH keys and
password authentication with redhatrst as the password.

[student@workstation ~]$ ssh -i RH362/labs/users-identities/idmuser06-key \

idmuser06@client
[idmuser06@lab.example.net@client ~]$ logout
[student@workstation ~]$ ssh idmuser06@client
Password: redhatrst
[idmuser06@lab.example.net@client ~]$ logout
[student@workstation ~]$

5. Verify that exceeding the failed login value locks the account.
5.1. From workstation, try to log back in to the client as the user idmuser06 using
password authentication. Use an incorrect password for the first 2 or 3 attempts by
using fedora as the password. You can then use the correct password, redhatrst
and it continues to fail because the account has been locked.

[student@workstation ~]$ ssh idmuser06@client

Password: fedora
Password: fedora
Password: fedora
idmuser06@client's password: redhatrst
Permission denied, please try again.
idmuser06@client's password: redhatrst

RH362-RHEL-7.4-en-1-20181003 253
CHAPTER 6 | Controlling User Access

Permission denied, please try again.

idmuser06@client's password: redhatrst
Authentication failed.
[student@workstation ~]$

5.2. From idm VM use the idm user-status command to verify that the failed logins
value is now set to 2 but the user account is enabled. This verifies that the account is
enabled but locked.

[root@idm ~]# ipa user-status idmuser06

-----------------------
Account disabled: False
-----------------------
Server: idm.lab.example.net
Failed logins: 2
Last successful authentication: N/A
Last failed authentication: 20180417054315Z
Time now: 2018-04-17T05:43:57Z
----------------------------
Number of entries returned 1
----------------------------

5.3. Use the web console to unlock the user account. To do so, navigate to Identities →
Users → Active Users and click the idmuser06 entry.
Click Unlock from the Actions menu and confirm the action.
5.4. From workstation, log in to the client as the idmuser06 with redhatrst as the
password. Use the passwd command to update the user password. When prompted,
use redhatrst as the password.

[student@workstation ~]$ ssh idmuser06@client

Password: redhatrst
[idmuser06@lab.example.net@client ~]$

Log out from the client server.

5.5. From the idm VM, use the idm user-status command to verify that the Failed
logins value is set back to 0 and that the user account is enabled. This verifies that
the account is enabled and unlocked.

[root@idm ~]# ipa user-status idmuser06

-----------------------
Account disabled: False
-----------------------
Server: idm.lab.example.net
Failed logins: 0
Last successful authentication: N/A
Last failed authentication: 20180417054315Z
Time now: 2018-04-17T06:08:47Z
----------------------------
Number of entries returned 1
----------------------------

254 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Cleanup
From the workstation VM, run the lab users-identities cleanup command to clean the
resources created in the exercise.

[student@workstation ~]$ lab users-identities cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 255
CHAPTER 6 | Controlling User Access

MANAGING USER ACCESS

OBJECTIVES
After completing this section, students should be able to:

• Configure Host-Based Access Control.

• Configure sudo access rules.

HOST-BASED ACCESS CONTROLS

Host-Based Access Control (HBAC) rules define which users or user groups can access specified
hosts or host groups by using specified services or services in a service group. HBAC rules allow
you to:

• Limit access to a specified system in your domain to members of a specific user group.

• Allow only a specific service to be used to access systems in your domain.

Administrators configure host-based access control by using a set of rules, called HBAC rules,
to allow a specific level of access. By default, IdM is configured with a default HBAC rule named
allow_all, which allows universal access in the entire IdM domain.

Applying HBAC Rules to Groups

For centralized and simplified access control management, you can apply HBAC rules to users,
hosts, or service groups instead of individual users, hosts, or services.

Conﬁgure Host-Based Access Control

To configure your domain for host-based access control:

1. Create HBAC rules.

2. Test the new HBAC rules.
3. Disable the default allow_all HBAC rule.

IMPORTANT
Do not disable the allow_all rule before creating custom HBAC rules. If you do
this, users will not be able to access any hosts.

Conﬁguring an HBAC Rule Using the Web UI

The following steps outline the process for creating an HBAC Rule using the web console:

1. Log in to the IdM web UI using the admin user account.

2. Navigate to the Policy → Host-Based Access Control → HBAC Rules menu choice.

3. Click Add to add a new rule.

4. Enter a name for the rule, and click Add and Edit to go to the HBAC rule configuration page.

5. In the Who area, specify the target users.

256 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

• To apply the HBAC rule to only specific users or groups, select Specified Users and Groups.
Click Add to add the users or groups.

• To apply the HBAC rule to all users, select Anyone.

6. In the Accessing area, specify the target hosts:

• To apply the HBAC rule to only specific hosts or groups, select Specified Hosts and Groups.
Then click Add to add the hosts or groups.

• To apply the HBAC rule to all hosts, select Any Host.

7. In the Via Service area, specify the target HBAC services:

• To apply the HBAC rule to only specific services or groups, select Specified Services and
Groups. Then click Add to add the services or groups.

• To apply the HBAC rule to all services, select Any Service.

8. Changing certain settings on the HBAC rule configuration page highlights the Save button at
the top of the page. If this happens, click the button to confirm the changes.

Testing HBAC Rules

IdM enables you to test your HBAC configuration in various situations using simulated scenarios.
By performing these simulated runs, you can discover incorrect configuration problems or security
risks before deploying HBAC rules in production.

IMPORTANT
IdM does not test the effect of HBAC rules on trusted Active Directory users.
Because Active Directory data is not stored in the IdM LDAP directory, IdM cannot
resolve group membership of Active Directory users when simulating HBAC
scenarios.

The following steps outline the process for testing an HBAC Rule using the web UI:

1. Log in to the IdM web UI as the administrative user.

2. Navigate to the Policy → Host-Based Access Control → HBAC Test menu choice.

3. On the Who screen, specify the user under whose identity you want to perform the test, and
click Next.

4. On the Accessing screen, specify the host that the user will attempt to access, and click Next.

5. On the Via Service screen, specify the service that the user will attempt to use, and click Next.

6. On the Rules screen, select the HBAC rules you want to test, and click Next. If you do not
select any rule, all rules are tested.

7. On the Run Test screen, click Run Test.

8. To review the test results:

• If you see ACCESS DENIED, the user is not granted access in the test.

• If you see ACCESS GRANTED, the user is able to access the host successfully.

RH362-RHEL-7.4-en-1-20181003 257
CHAPTER 6 | Controlling User Access

INTRODUCING SUDO ACCESS CONTROL

Identity Management provides a mechanism for predictably and consistently applying sudo
policies across the IdM domain. Every system in the IdM domain can be configured as a sudo client.

Describing the sudo Utility

The sudo utility gives administrative access to specified users. When trusted users precede an
administrative command with sudo, they are prompted for their own password. Then, when they
have been authenticated, the administrative command, assuming that the command is permitted,
is executed as if by the root user.

IdM LDAP Schema for sudo

IdM has a specialized LDAP schema for sudo entries. Although the LDAP schema supports both
host groups and netgroups, sudo only supports netgroups. However, sudo does support command
groups, which contain multiple commands.

IdM translates the IdM sudo configuration into the native sudo configuration when sudo rules are
created. For example, IdM creates a corresponding shadow netgroup for every host group, which
allows the IdM administrator to create sudo rules that reference host groups, while the local sudo
command uses the corresponding netgroup.

By default, sudo information is not available anonymously over LDAP. Therefore, IdM defines a
default sudo user at uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX. You can change this user
in the LDAP sudo configuration file at /etc/sudo-ldap.conf.

NIS Domain Name Requirements for Netgroups and sudo

Network information service (NIS) is a way to centrally manage identities and authentication
information, such as, users, passwords, host names, IP addresses, and POSIX groups.

Although NIS is considered insecure, it can be integrated with other protocols to enhance security.
IdM provides a server plug-in to connect clients that cannot be fully migrated to IdM and integrates
netgroups and other NIS data into the IdM domain.

The NIS domain name must be set for netgroups and sudo to work properly. The sudo
configuration requires NIS-formatted netgroups and a NIS domain name for netgroups. However,
IdM does not require the NIS domain to actually exist, nor is it required to have an NIS server
installed.

The ipa-client-install utility sets a NIS domain name automatically to the IdM domain name
by default.

ADDING SUDO COMMANDS, COMMAND GROUPS, AND

RULES
By using sudo rules, you can define who can do what, where, and as whom.

• Who are the users allowed to use sudo?

• What are the commands that can be used with sudo?
• Where are the target hosts on which the users are allowed to use sudo?
• As whom is the system or other user identity which the users assume to perform tasks?

External Users and Hosts in sudo Rules

IdM accepts external entities in sudo rules. External entities are entities that are stored outside of
the IdM domain, such as users or hosts, that are not part of the IdM domain.

258 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

For example, you can use sudo rules to grant root access to a member of the IT group in IdM,
where the root user is not a user defined in the IdM domain. Alternately, administrators can block
access to certain hosts on a network but that are not part of the IdM domain.

User Group Support for sudo Rules

You can use sudo to give access to whole user groups in IdM. IdM supports both Unix and non-
POSIX groups. Note that creating non-POSIX groups can cause access problems because any users
in a non-POSIX group inherit non-POSIX permissions from the group.

Adding sudo Commands

The following steps outline the process for adding sudo commands using the web console:

1. Log in to the IdM web UI using the account as the administrative user.

2. Navigate to Policy → Sudo → Sudo Commands menu choice.

3. Click Add at the top of the list.

4. In the Add Sudo Command form, fill out the information about the command. Enter the full
system path to the command, for example, /usr/bin/zip.

5. To add the command, click Add.

Adding sudo Command Groups

The following steps outline the process for adding sudo command groups using the web console:

1. Log in to the IdM web UI using the account as the administrative user.

2. Navigate to Policy → Sudo → Sudo Command Groups menu choice.

3. Click Add at the top of the list.

4. In the Add Sudo Command Group form, enter a name for the group in the Sudo Command
Group test box and an optional description in the Description test box.

5. Click Add and Edit button to edit the command group.

6. Under the Sudo Commands tab, click Add to add a sudo command to the group. Select the
required commands in the Available column and move them to the Prospective column using
the > button.

7. To confirm your entries, click the Add button.

Adding sudo Rules

The following steps outline the process for adding a sudo rule using the web console:

1. Log in to the IdM web UI using the account as the administrative user.

2. Navigate to Policy → Sudo → Sudo Rules menu choice.

3. Click Add at the top of the list.

4. In the Add Sudo Rule form, enter the name for the rule in the Rule name text field.

5. To confirm your rule entry, click the Add button.

RH362-RHEL-7.4-en-1-20181003 259
CHAPTER 6 | Controlling User Access

REFERENCES
Identity Management and Two-Factor Authentication Using One-Time
Passwords
https://rhelblog.redhat.com/2015/06/04/identity-management-and-two-factor-
authentication-using-one-time-passwords/#more-979

REFERENCES
Further information is available in the chapters on:

Using sudo in the Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication,
and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#sudo

Configuring Host-Based Access Control in the Red Hat Enterprise Linux 7 Linux
Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#configuring-
host-access

260 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

GUIDED EXERCISE

MANAGING USER ACCESS

In this exercise, you will configure user access rights using host-based and sudo
authorization policies.

OUTCOMES
You should be able to:

• Configure Host-Based access control.

• Configure sudo access rules.

Log in to workstation as student using student as the password. Run the lab users-
access setup command to configure the environment.

[student@workstation ~]$ lab users-access setup

1. From workstation, access the IdM console at https://idm.lab.example.com. Use

admin as the user name and RedHat123^ as the password.

2. Define a HBAC rule that allows a set of specified users to access the client over three
services:

• vSFTPD

• SSH

• FTP

Navigate to Policy → Host Based Access Control → HBAC Rules and click Add to create a
rule.
When prompted, create a rule named allow_remote_access and click Add and Edit to
edit the HBAC rule.

3. Create the rule according to the following specifications:

• In the Who frame, ensure that Specified Users and Groups is selected and click Add to
add a user. Select the users idmuser01, idmuser04, and idmuser05 and click the Add
arrow to move the selected users to the Prospective column.

Click Add to update the users list.

• In the Accessing frame, ensure that Specified Hosts and Groups is selected and click Add
to add a host. Select the client.lab.example.net host and click the Add arrow to
move the host to the Prospective column.

Click Add to update the hosts list.

RH362-RHEL-7.4-en-1-20181003 261
CHAPTER 6 | Controlling User Access

• In the Via Service frame, ensure that Specified Services and Groups is selected and click
Add to add a set of services. Enter ftp in the search field and click Filter to filter the
list. Select the ftp and vsftpd services from the filtered list. Move the two services to the
Prospective column by clicking the Add arrow.

Clear the search field. Enter ssh and then click Filter. Select the sshd entry and click the
Add arrow to move the service to the Prospective column. Click Add to close the window.

• Ensure that the three services are present in the Via Service frame. If not, click Add to
bring back the pop-up window and repeat the previous step.

4. Click the HBAC Rules link at the top of the window to list all available HBAC rules. Ensure
that there are two rules listed: allow_all and allow_remote_access. Select the
allow_all rule and click Disable to disable the rule. Click OK to confirm the deactivation
of the rule.

5. Create the ssh-copy-id service entry by navigating to Policy → Host Based Access
Control → HBAC Services. Click Add to create a new service entry. Enter ssh-copy-id in
the Service name and Description fields. Click Add to add the service.

6. Create the scp service entry by clicking Add a second time. Enter scp in the Service name
and Description fields. Click Add to add the service.

7. Create the Remote Access service by clicking the HBAC Service Groups link of the Host
Based Access Control menu.
Click Add to create a new service group. Use Remote Access for the Service group name
and the Description. Click Add and Edit to edit the service group.

8. Click Add to list all available services. Select the ssh-copy-id and scp services and click the
Add arrow to move the services to the Prospective column. Click Add to confirm.

9. Define a HBAC rule that allows a set of specified users to access the client via the remote
access service group.
9.1. Navigate to Policy → Host Based Access Control → HBAC Rules and click Add to
create a rule.
When prompted, create a rule named allow_ssh-copy-id_scp and click Add and
Edit to edit the HBAC rule.
9.2. Define the rule according to the following specifications:

• In the Who frame, ensure that Specified Users and Groups is selected and click
Add to add a user. Select the idmuser01 user and click the Add arrow to move the
user to the Prospective column.

Click Add to update the users list.

• In the Accessing frame, select Any Host.

• In the Via Service frame, ensure that Specified Services and Groups is selected
and click Add in the Service Groups row to add a service group.

Select the remote access service group and click the Add arrow to add the service
group to the list of prospective service groups. Click Add to close the window.

• Click the Save button to save the settings for the allow_ssh-copy-id_scp
HBAC rule.

262 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

10. Test the first HBAC rule that limits access to the client with SSH.
10.1. Click the HBAC Test link of the Host Based Access Control menu. Click Next on each
page to move to the next one.

1. From the WHO list, select idmuser03.

2. From the ACCESSING list, select client.lab.example.net.

3. From the VIA SERVICE list, select sshd.

4. From the RULES list, select allow_remote_access.

5. From the Run Test page, click Run Test to run the simulation.

The page should read ACCESS DENIED as the idmuser03 user is not member of
the HBAC rule.
10.2. From workstation, open a terminal and use the ssh command to log in to the
client VM as the idmuser03 user. The connection fails as the user is not a
member of the rule.

[student@workstation ~]$ ssh idmuser03@client

Authentication failed.

10.3. Repeat the previous step as the idmuser04 user and exit the client. The connection
succeeds as the user is a member of the rule.

[student@workstation ~]$ ssh idmuser04@client

-sh-4.2$ exit

11. Test the second HBAC rule that limits access to the ssh-copy-id and scp commands.
11.1. Click the HBAC Test link of the Host Based Access Control menu. Click Next on each
page to move to the next one.

1. From the WHO list, select idmuser01.

2. From the ACCESSING list, select client.lab.example.net.

3. From the VIA SERVICE list, select ssh-copy-id.

4. From the RULES list, select allow_ssh-copy-id_scp. Clear all other rules.

5. From the Run Test page, click Run Test to run the simulation.

The page should read Access Granted, as the idmuser01 user is a member of the
HBAC rule.
11.2. From workstation, open a terminal and use the ssh-copy-id command as the
idmuser01 to send the public key located at /home/student/RH362/labs/
users-access/idmuser01-key.pub. The command succeeds, as idmuser01 is
allowed to connect to the client via the command.

[student@workstation ~]$ ssh-copy-id \

-i RH362/labs/users-access/idmuser01-key.pub idmuser01@client
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "RH362/labs/users-
access/idmuser01-key.pub"

Number of key(s) added: 1

RH362-RHEL-7.4-en-1-20181003 263
CHAPTER 6 | Controlling User Access

Now try logging into the machine, with: "ssh 'idmuser01@client'"

and check to make sure that only the key(s) you wanted were added.

11.3. Log in to the client machine as idmuser01 and exit the client. Use the -i flag to
specify the SSH key to use.

[student@workstation ~]$ ssh -i RH362/labs/users-access/idmuser01-key \

idmuser01@client
-sh-4.2$ exit

11.4. Use the scp command to transfer the file transferme.txt located at /home/
student/RH362/labs/users/access. Use idmuser02. The command fails
because the user is not member of the rule.

[student@workstation ~]$ scp -o PubkeyAuthentication=no \

RH362/labs/users-access/transferme.txt idmuser02@client:
Password: RedHat123^
Authentication failed.

11.5. Rerun the previous step as the idmuser01 user. The command succeeds because
the user is a member of the rule.

[student@workstation ~]$ scp -o PubkeyAuthentication=no \

RH362/labs/users-access/transferme.txt idmuser01@client:
Password: RedHat123^
transferme.txt 100% 96 111.2KB/s 00:00

Cleanup
From the workstation VM, run the lab users-access cleanup command to clean the
resources created in the exercise.

[student@workstation ~]$ lab users-access cleanup

This concludes the guided exercise.

264 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

SECURING THE LOGIN PROCESS

OBJECTIVES
After completing this section, students should be able to:

• Configure single sign-on.

• Configure two-factor authentication.

• Configure one-time password tokens.

INTRODUCTION TO SINGLE SIGN-ON

By using single sign-on (SSO), users who log in to a system successfully for the first time can
access multiple services and applications without having to repeat the process of entering their
credentials. This method improves usability and productivity by obtaining quicker access to
services and applications. Additionally, it eliminates the security risk associated with writing
passwords and storing them in vulnerable or insecure locations.

Red Hat Enterprise Linux supports SSO for several resources, including logging into workstations,
unlocking screen savers, and accessing secured web pages using Mozilla Firefox.

Red Hat Enterprise Linux provides two authentication mechanisms which can be used to enable
SSO:

• Kerberos-based authentication, through both Kerberos realms and Active Directory domains.

• Smart card-based authentication.

Both of these methods create a centralized identity store (either through a Kerberos realm or a
certificate authority in a public key infrastructure), and the local system services then use those
identity domains rather than maintaining multiple local stores.

Conﬁguring Firefox to Use Kerberos for Single Sign-On

To configure Firefox to use Kerberos for SSO to intranet sites and other protected websites, it must
first be configured to send Kerberos credentials to the appropriate KDC. Firefox requires a valid
Kerberos ticket to use SSO. To generate a Kerberos ticket, use the kinit command and supply the
user password for the user on the KDC.

[user@demo ~]$ kinit user

Password for user@EXAMPLE.COM: password

To configure Firefox to use Kerberos for SSO:

1. In the address bar of Firefox, type about:config to display the list of current configuration
options.

2. In the Filter field, type negotiate to restrict the list of options.

3. Double-click the network.negotiate-auth.trusted-uris entry.

4. In the Enter string value text box, enter the name of the domain against which to authenticate,
including the preceding dot (.). For multiple domains, enter them in a comma-separated list.

RH362-RHEL-7.4-en-1-20181003 265
CHAPTER 6 | Controlling User Access

TWO-FACTOR AUTHENTICATION
Two-factor authentication (2FA) is an authentication mechanism that requires you to provide
a combination of two forms (factors) of information to authenticate to a service, application,
or system. A factor can be a device-generated passcode, a secret located on a smart card, or
something that you know such as a password, or a personal identification number (PIN).

One approach to two-factor authentication is to combine something you know, such as a PIN or
password, with something you have, such as a device-generated passcode.

ONE TIME PASSWORDS

A one-time password (OTP) is a random password token that is valid for only one authentication
session and becomes invalid after use. Unlike a traditional static password, an OTP keeps changing.
OTPs are used as part of two-factor authentication:

OTP Authentication Methods

Once you have enabled OTP, IdM allows you to choose between the following authentication
methods:

Two-factor authentication (password + OTP)

A user is always required to enter both a standard password and an OTP.

Password
A user has the option to authenticate using a standard password only.

RADIUS proxy server authentication

You can configure IdM as a client to one or more RADIUS servers.

OTP AUTHENTICATION IN IDM

IdM supports both software and hardware tokens. Users can manage their own tokens, or the
administrator can manage their tokens for them.

User-Managed Tokens
Users have full control over user-managed tokens in Identity Management: they are allowed to
create, edit, or delete their tokens.

Administrator-Managed Tokens
The administrator adds administrator-managed tokens to the users' accounts. Users have read-
only access to administrator-managed tokens but they do not have the permission to manage or
modify the tokens and they are not required to configure them in any way.

Supported OTP Algorithms

IdM supports the following two standard OTP mechanisms:

• The HMAC-Based One-Time Password (HOTP) algorithm is based on a counter. HMAC stands for
Hashed Message Authentication Code.

• The Time-Based One-Time Password (TOTP) algorithm is an extension of HOTP to support time-
based moving factor.

Generating an OTP Password Token

You can use an existing mobile device, such as your phone, along with an application such as
FreeOTP to generate an OTP passcode. FreeOTP, which represents an alternative software token
method for generating OTP passcodes can be downloaded to your mobile device from the Apple
App Store or from Google Play.

266 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Creating an Administrator-Managed Software Token

The following steps outline the process for creating and adding a software token as an
administrator using the web UI:

1. Log in to the IdM web UI as the administrative user.

2. Make sure the FreeOTP Authenticator application is installed on the mobile device.

3. Navigate to the Authentication → OTP Tokens panel.

4. At the top of the list of OTP tokens, click Add.

5. In the Add OTP Token form, select the Owner of the token.

Figure 6.1: Create and add an administrator-managed software token

6. To confirm and create the software token, click Add.

Alternatively, to create the token from the command line, run the ipa otptoken-add command
with the --owner option:

[root@idm ~]$ ipa otptoken-add --owner=user

A QR code is displayed in the web UI or on the command line. Scan the QR code with FreeOTP
Authenticator to provision the token to the mobile device.

CONFIGURING TWO-FACTOR AUTHENTICATION

OTPs are used as part of two-factor authentication:

1. The user authenticates with a traditional password.

2. The user provides a PIN combined with an OTP passcode, generated by a recognized OTP
token.

Two-factor authentication is considered safer than authentication using a traditional password

alone. Even if a potential intruder intercepts the OTP during login, the intercepted OTP will already
be invalid by that point because it can only be used for successful authentication once.

Conﬁguring a Global Authentication Method Using the Web UI

The following steps outline the process for creating a global authentication method for two-factor
authentication:

1. Log in to the IdM web UI using the account as the administrative user.

2. Navigate to IPA Server → Configuration menu choice.

3. In the User Options section on the right, scroll to the Default user authentication types
options list and check the box for the Two factor authentication (password+OTP) option.

4. To save your selection, navigate to the top of the Configuration page, click the Save button.

RH362-RHEL-7.4-en-1-20181003 267
CHAPTER 6 | Controlling User Access

Figure 6.2: Default Authentication Methods

Conﬁguring an individual user authentication method using the

web UI
The following steps outline the process for creating an individual user authentication method for
two-factor authentication:

1. Log in to the IdM web UI using the admin user account.

2. Navigate to the Identity → Users → Active users menu choice.

3. In the Active users panel, click the appropriate User login name.

4. In the Account Settings panel on the right, scroll to the User authentication types options list
and check the box for the Two factor authentication (password+OTP) option.

Figure 6.3: User Authentication Methods

RESTRICTING ACCESS TO A SPECIFIC

AUTHENTICATION METHOD
You can gain control over access to critical systems by configuring a host or service to require a
specific authentication method.

Conﬁguring Restricted Access to a Host or Service Using the

Web UI
The following steps outline the process for requiring a specific authentication method using the
web UI:

1. Log in to the IdM web UI using the admin user account.

2. Navigate to Identity → Hosts or Identity → Services menu choice.

3. Click the name of the host or service you want to restrict.

4. From the Authentication indicators list, select the authentication method you want to require
from users who want to access the restricted host or service.

• Select OTP to require Two-factor authentication. This ensures that only users who use a
valid OTP code with their password are allowed to access the host or service.

• If you select both OTP and RADIUS, then either OTP or RADIUS are sufficient to allow
access.

5. Click Save at the top of the page to apply your changes.

268 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Conﬁguring Restricted Access to a Host or Service Using the

Command-line Interface (CLI)
The following steps outline the process for requiring a specific authentication method using the
CLI:

1. Use the ipa host-find or ipa service-find command to identify the host or service
you want to configure for restricted authentication.

2. Use the ipa host-mod or the ipa service-mod command with the --auth-ind option
to specify the authentication method you want to require.

For example, to restrict access to only two-factor authentication for a host:

[root@idmserver ~]# ipa host host_name --auth-ind=otp

---------------------------------------------------------
Modified host "server.example.com"
---------------------------------------------------------
Host name: host_name
...output omitted...
Authentication Indicators: otp
...output omitted...

If indicators for both OTP and RADIUS are added, then either OTP or RADIUS are sufficient to
allow access.

CONFIGURING RADIUS PROXY

All two-factor servers provide a capability to authenticate using the RADIUS protocol. IdM
administrators can configure IdM as a client to one or more RADIUS servers.

An authentication policy for a user can be set to use a specific RADIUS server. Once the policy
is set to use RADIUS for a user, IdM ignores user passwords or tokens and instead sends user
credentials to a particular RADIUS server. Once it gets a response from the RADIUS server,
assuming successful authentication, it replies to its client with a Kerberos ticket; otherwise, it
denies user access.

This proxy approach allows a simple and gradual migration from a third-party solution to an IdM-
based solution. Such migration might be considered because of IdM's unique Kerberos integration
capability and the cost of the solution.

Migrating from a Proprietary OTP Solution

To enable migrating a large deployment from a proprietary OTP solution to the IdM-native OTP
solution, IdM offers a way to offload OTP validation to a third-party RADIUS server for a subset
of users. First, create a set of RADIUS proxies where each proxy can contain multiple individual
RADIUS servers. Then assign one of these proxy sets to a user. As long as the user has a RADIUS
proxy set assigned, IdM bypasses all other authentication mechanisms.

To configure a RADIUS server for OTP validation and to add a user to the proxy server:

1. Make sure that the RADIUS user authentication method is enabled, as presented earlier in this
section.

2. Run the ipa radiusproxy-add proxy_name command to add a RADIUS proxy. The
command prompts you for the required information.

3. Run the ipa user-mod radiususer --radius=proxy_name command to assign a user

to the added proxy.

RH362-RHEL-7.4-en-1-20181003 269
CHAPTER 6 | Controlling User Access

4. If required, configure the user name to be sent to RADIUS by running the ipa user-mod
radiususer --radius-username=radius_user command.

Once configured, the user OTP authentication is processed through the RADIUS proxy server.
When the user is ready to be migrated to the IdM native OTP system, remove the RADIUS proxy
assignment for the user.

REFERENCES
Further information is available in Part V. Administration: Managing Authentication
in the Red Hat Enterprise Linux 7, Linux Domain Identity, Authentication, and Policy
Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/
#p.administration-guide-authentication

270 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

GUIDED EXERCISE

SECURING THE LOGIN PROCESS

In this exercise, you will configure single sign-on access and one-time password
authentication.

OUTCOMES
You should be able to:

• Configure single sign-on.

• Verify single sign-on access.

• Configure one-time password authentication.

Log in to workstation as student using student as the password. Run the lab users-
login setup command to configure the environment.

[student@workstation ~]$ lab users-login setup

1. The utility.lab.example.net server has been joined to the IdM-controlled domain.

A Squid proxy server has been installed on the utility server. Start this exercise
by finishing the configuration required to allow Squid and Kerberos integration. From
workstation VM, open a terminal and use the ssh command to log in to the IdM server as
the student user, and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

2. Obtain a Kerberos ticket by running the kinit command. When prompted, use
RedHat123^ as the password.

[root@idm ~]# kinit

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3. If you did the exercises from the previous chapter, then this step is not necessary, because
the service has already been added. On idm server, create an HTTP service entry for the
utility.lab.example.net server.

[root@idm ~]# ipa service-add HTTP/utility.lab.example.net

RH362-RHEL-7.4-en-1-20181003 271
CHAPTER 6 | Controlling User Access

Managed by: utility.lab.example.net

4. From workstation, open a terminal and use SSH to log in to the utility server as the
student user, and then become root.

[student@workstation ~]$ ssh utility

[student@utility ~]$ sudo -i
[sudo] password for student: student
[root@utility ~]#

5. Obtain a Kerberos ticket by running the kinit admin command. When prompted, use
RedHat123^ as the password.

[root@utility ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

6. Use the ipa-getkeytab command, to obtain a new Kerberos krb5.keytab file for the
HTTP service on utility.

[root@utility ~]# ipa-getkeytab -s idm.lab.example.net \

-p HTTP/utility.lab.example.net \
-k /etc/squid/krb5.keytab
Keytab successfully retrieved and stored in: /etc/squid/krb5.keytab

7. Change the ownership of the krb5.keytab file to root:squid and set the permissions to
0640.

[root@utility ~]# chown root:squid /etc/squid/krb5.keytab

[root@utility ~]# chmod 0640 /etc/squid/krb5.keytab

8. A new Squid configuration file has already been created. Open that file and verify that the
Kerberos integration has been added properly.

[root@utility ~]# vim /etc/squid/squid.conf

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.

# Adapt to list your (internal) IP networks from where browsing
# should be allowed
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/
utility.lab.example.net
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl kerb_auth proxy_auth REQUIRED

...output omitted...

http_access allow kerb_auth

272 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

...output omitted...

9. To ensure that the correct krb5.keytab file is used, before starting squid service, modify
the /etc/sysconfig/squid file by adding the following lines at the end:

[root@utility ~]# vim /etc/sysconfig/squid

...output omitted...
KRB5_KTNAME=/etc/squid/krb5.keytab
export KRB5_KTNAME

10. The required firewall ports have already been opened. Restart the squid service.

[root@utility ~]# systemctl restart squid

11. Open the graphical console of the client VM and log in to the server as the idmuser04
user with RedHat123^ as password. Click the Not listed? button and log in as the
idmuser04.

12. Ignore the Welcome window. Configure Firefox to use the new proxy server.
12.1. On the client server, open the Firefox browser.
12.2. In the address bar, type about:preferences.
12.3. In the left pane, click the Advanced button.
12.4. Click on the Network tab.
12.5. Click the Settings button.
12.6. A new Connection Settings window opens. Mark the radio button next to Manual
proxy configuration to set up the proxy for Firefox.
12.7. In the HTTP Proxy text field, type utility.lab.example.net as the name of the
proxy server to use. Change the port from 0 to 3128. Select the check box next to
Use this proxy server for all protocols.
Leave everything else as it is and click the OK to accept the changes.

13. Open a new tab in Firefox and go to the IdM web UI at http://idm.lab.example.net.
If the login page of the Red Hat Identity Management web UI appears, then Squid and
Kerberos integration works as expected.

14. To enable single sign-on, on the login page of the Red Hat Identity Management web UI,
enter about:config in the address bar. This displays the current Firefox configuration.
Click I accept the risk.
14.1. Enter negotiate in the Search field.
14.2. Double-click network.negotiate-auth.trusted-uris. Enter
lab.example.net as the name of the domain to authenticate against, and then
click OK. Close the about:config tab in your Firefox browser.

RH362-RHEL-7.4-en-1-20181003 273
CHAPTER 6 | Controlling User Access

15. In the Firefox web browser, reconnect to https://idm.lab.example.net. You are now
automatically logged in to Red Hat Identity Management web UI using the cached Kerberos
credential for the idmuser04 user.

NOTE
The following part of the exercise requires the use of either an Android or iPhone
smartphone. To configure one-time passwords, you need to install an external Red
Hat sponsored application, or a QR code scanning application if you do not have one.
If you do not wish to install anything on your mobile device, consider this exercise as
concluded and perform the cleanup task. The remaining steps require the use of a
QR code scanner on your mobile device at a minimum.

16. On the client server, open a terminal and request a Kerberos ticket as the idmuser02
user with RedHat123^ as password.

sh-4.2$ kinit idmuser02

Password for idmuser02@LAB.EXAMPLE.NET: RedHat123^

17. On the idm server, use the ipa user-mod idmuser02 --user-auth-type=otp
command to set the two-factor authentication for the idmuser02 user.

[root@idm ~]# ipa user-mod idmuser02 --user-auth-type=otp

-------------------------
Modified user "idmuser02"
-------------------------
User login: idmuser02
First name: idmuser02
Last name: idm
Home directory: /home/idmuser02
Login shell: /bin/sh
Principal name: idmuser02@LAB.EXAMPLE.NET
Principal alias: idmuser02@LAB.EXAMPLE.NET
Email address: idmuser02@example.net
UID: 12400003
GID: 12400003
User authentication types: otp
Account disabled: False
Password: True
Member of groups: ipausers
Kerberos keys available: True

18. On your mobile device, search for and install the FreeOTP Authenticator application.
If you choose not to install FreeOTP on your mobile devices, an alternate method using any
QR code scanner is provided.

19. On the idm server, use the ipa otptoken-add command to create the user-managed
software token. Use the --desc=phone option to set the description and the --owner
option to assign the correct user.

[root@idm ~]# ipa otptoken-add --desc=phone --owner=idmuser02

274 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

20. Scan the displayed QR code with the FreeOTP Authenticator to provision the token to the
mobile device.
As an alternative, use a QR code scanner to scan the QR code.

21. On the client system, reconnect to https://idm.lab.example.net using the Firefox

web browser. If you are automatically logged in to Red Hat Identity Management web UI, log
out from the dashboard.

22. On the Red Hat Identity Management web UI, log in as the idmuser02 user. Type in
idmuser02 in the Username text field.
Type in RedHat123^ as the PIN part of the one-time password. Use the FreeOTP
application to generate a passcode then append it to the PIN. The two items combined form
the OTP.
Click Login. If authentication fails, remember that the passcode is only valid for
approximately 25 seconds, so you have to be quick when using it.

NOTE
If you used the QR scanner, use the oathtool --base32 --totp command to
generate the required passcode. In the URI displayed on your mobile device, find
the secret= value and use that string as the argument for the --totp option. On
workstation type in the following command:

[student@workstation ~]$ oathtool --base32 \

--totp NXSI5HAPV3GH2O2RG6PEKXHBJYYTASKO
350759

Type the generated passcode in at the end of the password, then click Login.

Cleanup
From workstation, run the lab users-login cleanup command to clean up after this
exercise.

[student@workstation ~]$ lab users-login cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 275
CHAPTER 6 | Controlling User Access

MANAGING IDM USER ACCESS RULES

OBJECTIVES
After completing this section, students should be able to:

• Configure self-service management rules.

• Configure user management delegation.

• Configure role-based access control.

INTRODUCTION TO AUTHENTICATION MECHANISMS

Different mechanisms for Kerberos authentication in IdM can be represented by different
authentication strengths. Services that have security sensitive content can be required to use
stronger authentication methods than less critical services.

The authentication mechanisms supported by IdM have different strengths. For example,
authentication using a one-time password (OTP) in combination with a standard password is
considered stronger and therefore safer than authentication using a standard password only. This
section shows how to limit access to services and hosts based on how the user authenticates.

For example:

• Configure services critical to security, such as VPN, to require a strong authentication method.

• Configure noncritical services, such as local logins, to allow authentication using a weaker, but
more convenient authentication method.

Authentication Indicators
Access to services and hosts is defined by authentication indicators:

• Indicators included in a service or host entry define what authentication methods the user can
use to access that service or host.

• Indicators included in the user's ticket-granting ticket (TGT) show what authentication method is
used to obtain the ticket.

If the indicator in the principal does not match the indicator in the TGT, the user is denied access.

276 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Figure 6.4: Authentication methods with indicators

Notice in the above diagram that User 1 successfully authenticates to the VPN service. However,
User 2 does not. This is because the indicator in the TGT of User 2 does not match the indicator
in the principal of the VPN service.

MANAGING ACCESS CONTROLS IN IDM

Access control defines the rights or permissions users have been granted to perform operations on
other users or objects.

The Identity Management access control structure is based on standard LDAP access controls.
Access within the IdM server is based on IdM users stored in the back-end Directory Server
instance. The instance is allowed to access other IdM entities, which are also stored as LDAP
entries in the Directory Server instance.

An access control instruction (ACI) has three parts:

Actor
This is the entity being granted permission to perform an action. In LDAP access control
models, this is called the bind rule because it defines who the user is and can optionally
require other limits on the bind attempt, such as restricting attempts to a certain time of day
or a certain machine.

Target
The target defines the entry for which the user is able to perform operations.

Operation type
The operation type determines the actions that the user is allowed to perform. The most
common operations are add, delete, write, read, and search. In Identity Management, all users
are implicitly granted read and search rights to all entries in the IdM domain, with restrictions
only for sensitive attributes such as passwords and Kerberos keys. Anonymous users are
restricted from seeing security-related configuration, which includes sudo rules and host-
based access control.

When any operation is attempted, the first thing that the IdM client does is send user credentials as
part of the bind operation. The Directory Server checks the user credentials and then verifies the
user account to see whether the user has permission to perform the requested operation.

To make access control rules simple and clear to implement, IdM divides access control definitions
into three categories:

RH362-RHEL-7.4-en-1-20181003 277
CHAPTER 6 | Controlling User Access

Self-service rules
Self-service rules define what operations a user can perform on his own personal entry. The
access control type only allows write permissions to attributes within the entry. It does not
allow add or delete operations for the entry itself.

Delegation rules
Delegation rules allow a specific user group to perform write (edit) operations on specific
attributes for users in another user group. Like self-service rules, this form of access control
rule is limited to editing the values of specific attributes. It does not grant the ability to add or
remove whole entries or control over unspecified attributes.

Role-based access control

Role-based access control creates special access control groups, which are then granted much
broader authority over all types of entities in the IdM domain. Roles can be granted edit, add,
and delete rights, meaning they can be granted complete control over entire entries, not just
selected attributes.

Some roles are already created and available within IdM. Special roles can be created to
manage any type of entry in specific ways, such as hosts, automount configuration, netgroups,
DNS settings, and IdM configuration.

Conﬁguring Self-Service Rules Using the Web UI

Self-service access control rules define the operations that an entity can perform on itself. These
rules define only what attributes a user (or other IdM entity) can edit on their personal entries.

1. Log in to the IdM web UI using the account as the administrative user. Log in to the IdM web UI
using the account that will use the self-service rule.

2. Navigate to the IPA Server → Role-Based Access Control → Self Service Permissions menu
choice.

3. To create a self service permissions list, at the top right of the Self Service Permissions page,
click the Add button.

4. Enter the name of the rule in the Self-service name text box. Spaces are allowed.

5. Select the check boxes next to the attributes which the access control instruction (ACI) will
permit users to edit.

6. Click the Add button to save the new self-service ACI.

Conﬁguring Self-Service Rules Using the Command Line

A new self-service rule can be added using the selfservice-add command.

The following two options are required:

--permissions to set which permissions, such as write, add, or delete for the ACI grants

--attrs to give the full list of attributes which the ACI grants permission to

[user@idm ~]$ ipa selfservice-add \

"Users can manage their own name details" \
--permissions=write --attrs=givenname \
--attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
Self-service name: Users can manage their own name details

278 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Permissions: write
Attributes: givenname, displayname, title, initials

Conﬁguring User Management Delegation

Delegation is very similar to roles: one group of users is assigned permission to manage the entries
for another group of users. However, the delegated authority is much more similar to self-service
rules, because complete access is granted to specific user attributes rather than to the entire
entry. Moreover, the groups in delegated authority are existing IdM user groups instead of roles
specifically created for access controls.

The following steps outline the process for delegating access to a user group in the web console:

1. Log in to the IdM web UI using the administrator's account.

2. Navigate to the IPA Server → Role-Based Access Control → Delegations menu choice.

3. To create a ne delecation, at the top right of the Delegations page, click the Add button.

4. In the Add Delegation form, enter a descriptive name for the new access control instruction in
the Delegation name text field.

5. Select the appropriate check box to determine whether users have read or write permission for
the give attributes.

6. In the User group drop-down list, select the group being granted permission to edit the entries
of users in other groups.

7. In the Member user group drop-down menu, select the group whose entries can be edited by
members of the new delegation group.

8. In the Attributes section, select the check boxes by the attributes to which the members of the
delegation group are being granted permission.

9. Click the Add button to save the new delegation ACI.

Conﬁguring User Management Delegation Using the CLI

A new delegation access control rule is added using the delegation-add command.

The following three arguments are required:

--group to define the group being granted permission to the entries in the user group

--membergroup to define the group whose entries can be edited by members of the delegation
group

--attrs to define the attributes that users in the delegation group are allowed to view or edit

[user@idm ~]$ ipa delegation-add "basic manager attrs" \

--attrs=manager --attrs=title --attrs=employeetype \
--attrs=employeenumber --group=engineering_managers \
--membergroup=engineering
--------------------------------------
Added delegation "basic manager attrs"
--------------------------------------
Delegation name: basic manager attrs
Permissions: write
Attributes: manager, title, employeetype, employeenumber
Member user group: engineering

RH362-RHEL-7.4-en-1-20181003 279
CHAPTER 6 | Controlling User Access

User group: engineering_managers

Modifying Delegation Attributes Using the CLI

Delegation rules are edited using the delegation-mod command. The --attrs option
overwrites the previous list of supported attributes, so always include the complete list of
attributes along with any new attributes.

Conﬁguring Role-Based Access Controls

Role-based access controls are fundamentally administrative, providing the ability to modify
entries.

There are three parts to role-based access controls: permission, privilege, and role. A privilege
consists of one or more permissions, and a role consists of one or more privileges.

permission
A permission defines a specific operation or set of operations (such as read, write, add, or
delete) and the target entries within the IdM LDAP directory to which those operations apply.
Permissions are building blocks, they can be assigned to multiple privileges as needed.

With IdM permissions, you can control which users have access to which objects and even
which attributes of such objects. IdM enables you to allow or deny individual attributes or
change the entire visibility of a specific IdM function, such as users, groups, or sudo, to all
anonymous users, all authenticated users, or just a certain group of privileged users. This
flexible approach to permissions is useful in scenarios when, for example, the administrator
wants to limit access of users or groups only to the specific sections these users or groups
need to access and to make the other sections completely hidden to them.

privilege
A privilege is a group of permissions that can be applied to a role. For example, a permission
can be created to add, edit, and delete automount locations. Then that permission can be
combined with another permission relating to managing FTP services, and it can be used to
create a single privilege that relates to managing file systems.

role
A role is a list of privileges that users specified for the role possess.

It is possible to create entirely new permissions, as well as to create new privileges based on
existing permissions or new permissions. Red Hat Identity Management provides the following
range of predefined roles.

The following steps outline the process for creating a role in the web UI:

1. Log in to the IdM web UI using the account as the administrative user.

2. Navigate to the IPA Server → Role-Based Access Control → Roles menu choice.

3. To add a role, from the right side of the Roles page, click the Add button.

4. In the Add Role form, enter a role name in the Role name text box and a description in the
Description text box.

5. Click Add or Add and Edit to save the new role.

6. On the Role:role name page, at the top, in the Users tab, or in the Users Groups tab when
adding groups, click the Add button.

7. Select the users on the left and use the > button to move them to the Prospective column.

8. At the top of the Privileges tab, click Add.

280 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

9. Select the privileges on the left and use the > button to move them to the Prospective column.

10. Click Add to save.

Creating a New Role Using the Command Line

The following steps outline the process for creating a role using the command-line interface:

1. Acquire Kerberos credentials for the admin user on the IdM server using the kinit admin
command.

2. Add a new role using the ipa role-add command.

[root@idm ~]# ipa role-add \

--desc="role_description" role_name
------------------------
Added role "role_name"
------------------------
Role name: role_name
Description: role_description

3. Add the required privileges to the role.

[root@idm ~]# ipa role-privilege \

--privileges="privilege" role_name
Role name: role_name
Description: role_description
Privileges: privileges
----------------------------
Number of privileges added 1
----------------------------

4. Add the required groups to the role.

[root@idm ~]# ipa role-add-member \

--groups="group_name" role_name
Role name: role_name
Description: role_description
Member groups: group_name
Privileges: privileges
-------------------------
Number of members added 1
-------------------------

REFERENCES
Further information is available in the chapter on Defining Access Control for IdM
Users in the Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and
Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#server-
access-controls

RH362-RHEL-7.4-en-1-20181003 281
CHAPTER 6 | Controlling User Access

GUIDED EXERCISE

MANAGING IDM USER POLICIES

In this exercise, you will configure self-service management rules, user management
delegation, and role-based access control.

OUTCOMES
You should be able to:

• Configure self-service management rules.

• Configure user management delegation.

• Configure role-based access control.

Log in to workstation as student using student as the password. Run the lab users-
policies setup command to configure the environment.

[student@workstation ~]$ lab users-policies setup

1. On workstation, open the Firefox browser and go to the IdM web UI at http://
idm.lab.example.net.

2. Log in as the idmuser02 user with RedHat123^ as password.

Once logged in, take a note of the various fields that the user is allowed to modify, for
example: Last name, Full name, and Mailing Address.

3. Log out from the IdM web UI.

4. From workstation, open a terminal and use SSH to log in to the idm server as student,
and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

5. Obtain a Kerberos ticket by running the kinit admin command. When prompted, use
RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

6. Use the ipa selfservice-find command to view the list of the defined self-service
management rules.

282 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

[root@idm ~]# ipa selfservice-find

----------------------
5 selfservices matched
----------------------
Self-service name: Self can write own password
Permissions: write
Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword

Self-service name: User Self service

Permissions: write
Attributes: givenname, sn, cn, displayname, title, initials, loginshell, gecos,
homephone, mobile, pager, facsimiletelephonenumber,
telephonenumber, street, roomnumber, l, st, postalcode, manager,
secretary, description, carlicense, labeleduri, inetuserhttpurl,
seealso, employeetype, businesscategory, ou

Self-service name: Users can manage their own SSH public keys
Permissions: write
Attributes: ipasshpubkey

Self-service name: Users can manage their own X.509 certificates

Permissions: write
Attributes: usercertificate

Self-service name: Users can manage their own X.509 certificate identity
mappings
Permissions: write
Attributes: ipacertmapdata
----------------------------
Number of entries returned 5
----------------------------

Notice the User Self service rule. That rule defines the permissions and attributes
that IdM users are allowed to change.

7. Use the ipa selfservice-mod command to modify the User Self service rule
so that users are only allowed to change their givenname, displayname, title, and
initials.

[root@idm ~]# ipa selfservice-mod "User Self service" \

--permissions=write --attrs=givenname \
--attrs=displayname --attrs=title \
--attrs=initials
----------------------------------------
Modified selfservice "User Self service"
----------------------------------------
Self-service name: User Self service
Permissions: write
Attributes: givenname, displayname, title, initials

Notice the changed attributes defining what users are allowed to modify.

8. On workstation, open the Firefox browser and go to the IdM web UI at http://
idm.lab.example.net.

RH362-RHEL-7.4-en-1-20181003 283
CHAPTER 6 | Controlling User Access

9. Log in as the idmuser02 user with RedHat123^ as password.

Once logged in, notice that under Identity Settings the user is now only allowed to modify
Job Title, First name, Display name, and Initials. Additionally, all fields under Mailing
Address are blocked.

10. From workstation, open a terminal and use SSH to log in to the idm server as student
then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

11. Use the ipa selfservice-add command to create new self-service management rules
that allow users to modify their email address.

[root@idm ~]# ipa selfservice-add "Users can modify email details" \

--permissions=write --attrs=mail
--------------------------------------------------
Added selfservice "Users can modify email details"
--------------------------------------------------
Self-service name: Users can modify email details
Permissions: write
Attributes: mail

12. On workstation refresh the IdM web UI page at http://idm.lab.example.net.

13. Take another look at the fields that the user is allowed to modify. The Email address
attribute is now accessible for the users to modify.

14. This next example shows how members of one group can be delegated to be able to modify
specific values for members of another group.
From workstation, open a terminal and use SSH to log in to the idm server as student,
and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

15. Use the ipa group-find command to list all the available user groups.

[root@idm ~]# ipa group-find

----------------
7 groups matched
----------------
Group name: admins
Description: Account administrators group
GID: 1380800000

Group name: editors

284 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Description: Limited admins who can edit other users

GID: 1380800002

Group name: idmgroup01

GID: 1380800007

Group name: idmgroup02

GID: 1380800008

Group name: idmgroup03

GID: 1380800009

Group name: ipausers

Description: Default group for all users

Group name: trust admins

Description: Trusts administrators group
----------------------------
Number of entries returned 7
----------------------------

16. Use the ipa group-add-member command to add the idmuser02 user to the
idmgroup02 group.

[root@idm ~]# ipa group-add-member idmgroup02 --users=idmuser02

Group name: idmgroup02
GID: 1380800008
Member users: idmuser02
-------------------------
Number of members added 1
-------------------------

17. Use the ipa delegation-add command to add a new delegation for the idgroup02
group so that members of this group can modify attributes of members of the idmgroup03
group.

[root@idm ~]# ipa delegation-add "Manager Attrs" \

--attrs=manager --attrs=title \
--attrs=employeetype --attrs=employeenumber \
--group=idmgroup02 --membergroup=idmgroup03
--------------------------------
Added delegation "Manager Attrs"
--------------------------------
Delegation name: Manager Attrs
Permissions: write
Attributes: manager, title, employeetype, employeenumber
Member user group: idmgroup03
User group: idmgroup02

18. On workstation, refresh the IdM web UI page at http://idm.lab.example.net.

19. Click the Active users link.

RH362-RHEL-7.4-en-1-20181003 285
CHAPTER 6 | Controlling User Access

20. From the Active users list, click the idmuser03 user, who is a member of the idmgroup03.

21. Scroll down to the Employee Information fields. Click the drop-down list in the Manager
field and assign the idmuser02 as the manager.

22. Scroll up to the top of the page and click the Save button to save the change.

23. From workstation, open a terminal and use SSH to log in to the idm server as student,
and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

24. Use the ipa role-find command to list all the default roles.

[root@idm ~]# ipa role-find

---------------
5 roles matched
---------------
Role name: helpdesk
Description: Helpdesk

Role name: IT Security Specialist

Description: IT Security Specialist

Role name: IT Specialist

Description: IT Specialist

Role name: Security Architect

Description: Security Architect

Role name: User Administrator

Description: Responsible for creating Users and Groups
----------------------------
Number of entries returned 5
----------------------------

25. Use the ipa role-show "User Administrator" command to access the details of the
User Administrator role.

[root@idm ~]# ipa role-show "User Administrator"

Role name: User Administrator
Description: Responsible for creating Users and Groups
Privileges: User Administrators, Group Administrators, Stage User Administrators

26. Use the ipa role-add command to add a new groupadmin role to the environment.

[root@idm ~]# ipa role-add --desc="Group Administrator" groupadmin

-----------------------

286 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

Added role "groupadmin"

-----------------------
Role name: groupadmin
Description: Group Administrator

27. Use the ipa role-add-privilege command to add the Group Administrators
privilege to the groupadmin role.

[root@idm ~]# ipa role-add-privilege --privileges="Group Administrators"

groupadmin
Role name: groupadmin
Description: Group Administrator
Privileges: Group Administrators
----------------------------
Number of privileges added 1
----------------------------

28. Use the ipa role-add-member command to add the idmgroup02 group to the
groupadmin role.

[root@idm ~]# ipa role-add-member --groups=idmgroup02 groupadmin

Role name: groupadmin
Description: Group Administrator
Member groups: idmgroup02
Privileges: Group Administrators
-------------------------
Number of members added 1
-------------------------

29. On workstation refresh the IdM web UI page at http://idm.lab.example.net.

Notice how the interface changed accordingly to the new role that the idmuser02 user
inherited.

30. Click the Groups tab.

31. From the User Groups list, click the idmgroup03 group.

32. Click the Add button.

33. In the Add Users into User Group idmgroup03 dialog window, mark the check box next to
the idmuser05 user and click the > button to add that user to the group.

34. Click the Add button to accept the change.

The new added idmuser05 user appears on the user list of the idmgroup03 group.

Cleanup
From workstation, run the lab users-policies cleanup command to clean up this
exercise.

RH362-RHEL-7.4-en-1-20181003 287
CHAPTER 6 | Controlling User Access

[student@workstation ~]$ lab users-policies cleanup

This concludes the guided exercise.

288 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

LAB

CONTROLLING USER ACCESS

PERFORMANCE CHECKLIST
In this lab, you will create users and configure life-cycle settings, access policies, and user
management policies.

OUTCOMES
You should be able to:

• Create users and configure life-cycle settings.

• Configure user access policies.

• Configure user management policies.

Log in to workstation as student using student as the password. Run the lab users-
review setup command to configure the environment.

[student@workstation ~]$ lab users-review setup

1. In the lab.example.net domain, create a new user according to the following information.

FIELD VALUE

User login idmuser07

First name idmuser07

Last name idm

New Password and Verify Password RedHat123^

2. Open a terminal on workstation and us SSH to log in to the idm server. Use the ipa
user-mod command to change the idmuser07 user shell to /bin/bash.
3. Create a new HBAC rule called allow_ssh that allows the idmuser07 user SSH access to
the client.lab.example.net server. Make sure that the allow_all rule is disabled.
4. From workstation, use the ssh command to log in to the client VM as the idmuser07
user with RedHat123^ as password.
5. Make the idmuser07 user a member of a new mgmt group. Create a new Mgmt attr
delegation for the mgmt group so that the members of this group can modify the manager
and employeetype attributes of the idmgroup02 group.
6. A new employee is joining the company next week. Create a new staged type account for that
new user, set the authentication type for that new user to the two-factor authentication. Use
the following information to create the new account:

RH362-RHEL-7.4-en-1-20181003 289
CHAPTER 6 | Controlling User Access

FIELD VALUE

User login idmuser08

First name idmuser08

Last name idm

New Password and Verify Password RedHat123^

7. One of the existing employees has just retired. Make sure that the retired idmuser04 user is
not able to use any of the company's systems. Retain the retired user data in the domain.

Evaluation
From workstation, run the lab users-review grade command to confirm the success of
this exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab users-review grade

Cleanup
From workstation, run the lab users-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab users-review cleanup

This concludes the lab.

290 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

SOLUTION

CONTROLLING USER ACCESS

PERFORMANCE CHECKLIST
In this lab, you will create users and configure life-cycle settings, access policies, and user
management policies.

OUTCOMES
You should be able to:

• Create users and configure life-cycle settings.

• Configure user access policies.

• Configure user management policies.

Log in to workstation as student using student as the password. Run the lab users-
review setup command to configure the environment.

[student@workstation ~]$ lab users-review setup

1. In the lab.example.net domain, create a new user according to the following information.

FIELD VALUE

User login idmuser07

First name idmuser07

Last name idm

New Password and Verify Password RedHat123^

1.1. On workstation use the Firefox browser to log in to the Red Hat Identity
Management web interface at https://idm.lab.example.net. Authenticate as
the admin user with the password RedHat123^.
1.2. As the admin user, create a new user by navigating to Identity → Users → Active
users. Click Add to create a new user.
Create the new user according to the following information. Leave all other fields
untouched.

FIELD VALUE

User login idmuser07

First name idmuser07

Last name idm

RH362-RHEL-7.4-en-1-20181003 291
CHAPTER 6 | Controlling User Access

FIELD VALUE

New Password and Verify Password RedHat123^

Click the Add button to create the user.

2. Open a terminal on workstation and us SSH to log in to the idm server. Use the ipa
user-mod command to change the idmuser07 user shell to /bin/bash.
2.1. From workstation use SSH to log in to the idm server then become root. Request a
Kerberos ticket for the admin user, using RedHat123^ as password.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

2.2. Use the ipa user-mod --shell=/bin/bash to modify idmuser07 user login
shell.

[root@idm ~]# ipa user-mod --shell=/bin/bash idmuser07

-------------------------
Modified user "idmuser07"
-------------------------
User login: idmuser07
First name: idmuser07
Last name: idm
Home directory: /home/idmuser07
Login shell: /bin/bash
Principal name: idmuser07@LAB.EXAMPLE.NET
Principal alias: idmuser07@LAB.EXAMPLE.NET
Email address: idmuser07@lab.example.net
...output omitted...

292 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

3. Create a new HBAC rule called allow_ssh that allows the idmuser07 user SSH access to
the client.lab.example.net server. Make sure that the allow_all rule is disabled.
3.1. From workstation, access the IdM console at https://idm.lab.example.com.
Use admin as the user name and RedHat123^ as the password.
3.2. Navigate to Policy → Host Based Access Control → HBAC Rules and click Add to
create a rule.
When prompted, create a rule named allow_ssh and click Add and Edit to edit the
HBAC rule.
3.3. Create the rule according to the following specifications:

• In the Who frame, ensure that Specified Users and Groups is selected and click Add
to add a user. Select the idmuser07 user and click the Add arrow to move the user
to the Prospective column.

Click Add to update the users list.

• In the Accessing frame, ensure that Specified Hosts and Groups is selected and click
Add to add a host. Select the users client.lab.example.net host and click the
Add arrow to move the host to the Prospective column.

Click Add to update the hosts list.

• In the Via Service frame, ensure that Specified Services and Groups is selected and
click Add to add a set of services. Type ssh into the search field, and click Filter.
Select the sshd entry and move the service to the Prospective column by clicking
the Add arrow. Click Add to apply your changes and to close the window.
3.4. Ensure that the allow_all rule is disabled. Click the HBAC Rules link at the top of
the window to list all available HBAC rules. If necessary, select the allow_all rule
and click Disable to disable the rule. Click OK to confirm the deactivation of the rule.
4. From workstation, use the ssh command to log in to the client VM as the idmuser07
user with RedHat123^ as password.
From workstation, open a terminal and use the ssh command to log in to the client VM
as the idmuser07 user. Request a Kerberos ticket for the idmuser07 user. When prompted,
enter RedHat123^ as the password.

[student@workstation ~]# ssh idmuser07@client

[idmuser07@lab.example.net@client ~]$ kinit idmuser07
Password for idmuser04@LAB.EXAMPLE.NET: RedHat123^
[idmuser07@lab.example.net@client ~]$ logout

5. Make the idmuser07 user a member of a new mgmt group. Create a new Mgmt attr
delegation for the mgmt group so that the members of this group can modify the manager
and employeetype attributes of the idmgroup02 group.
5.1. From workstation, open a terminal and use SSH to log in to the idm VM as
student, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student

RH362-RHEL-7.4-en-1-20181003 293
CHAPTER 6 | Controlling User Access

[root@idm ~]#

5.2. Use the ipa group-add command to create the mgmt group.

[root@idm ~]# ipa group-add mgmt

------------------
Added group "mgmt"
------------------
Group name: mgmt
GID: 1285800015

5.3. Use the ipa group-add-member --users=idmuser07 mgmt command to add

the idmuser07 user to the mgmt group.

[root@idm ~]# ipa group-add-member \

--users=idmuser07 mgmt
Group name: mgmt
GID: 1285800015
Member users: idmuser07
-------------------------
Number of members added 1
-------------------------

5.4. Use the ipa delegation-add command to add a new delegation for the mgmt
group so that members of this group can modify attributes of members of the
idmgroup02 group.

[root@idm ~]# ipa delegation-add "Mgmt attr" \

--attrs=manager --attrs=employeetype \
--group=mgmt --membergroup=idmgroup02
--------------------------------
Added delegation "Mgmt attr"
--------------------------------
Delegation name: Mgmt attr
Permissions: write
Attributes: manager, employeetype
Member user group: idmgroup02
User group: mgmt

6. A new employee is joining the company next week. Create a new staged type account for that
new user, set the authentication type for that new user to the two-factor authentication. Use
the following information to create the new account:

FIELD VALUE

User login idmuser08

First name idmuser08

Last name idm

294 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

FIELD VALUE

New Password and Verify Password RedHat123^

6.1. From workstation, use SSH to log in to the idm server as the root user.
6.2. Use the ipa stageuser-add command to add the new staged user.

[root@idm ~]# ipa stageuser-add idmuser08 \

--first=idmuser08 \
--last=idm \
--password
Password: RedHat123^
Enter Password again to verify: RedHat123^
-----------------------------
Added stage user "idmuser08"
-----------------------------
User login: idmuser08
First name: idmuser08
Last name: idm
Full name: idmuser08 idm
Display name: idmuser08 idm
Initials: ii
Home directory: /home/idmuser08
GECOS: idmuser08 idm
Login shell: /bin/sh
Principal name: idmuser08@LAB.EXAMPLE.NET
Principal alias: idmuser08@LAB.EXAMPLE.NET
Email address: idmuser08@lab.example.net
Password:
e1NTSEE1MTJ9YTVUUEpJbzlwS2kyTUhtTFRNOEhZQXVKVC9iRzF1ZWQyZjYxLzl0ekd6NmczcUIyMlBOcXI1RWF6WmJETGkwcTg5K0
UID: -1
GID: -1
Password: True
Kerberos keys available: True

6.3. Use the ipa stageuser-mod command to set the authentication type to otp.

[root@idm ~]# ipa stageuser-mod --user-auth-type=otp idmuser08

--------------------------------
Modified stage user "idmuser08"
--------------------------------
User login: idmuser08
First name: idmuser08
Last name: idm
Home directory: /home/idmuser08
Login shell: /bin/sh
Principal name: idmuser08@LAB.EXAMPLE.NET
Principal alias: idmuser08@LAB.EXAMPLE.NET
Email address: idmuser08@lab.example.net
UID: -1
GID: -1
User authentication types: otp
Password: True
Kerberos keys available: True

RH362-RHEL-7.4-en-1-20181003 295
CHAPTER 6 | Controlling User Access

7. One of the existing employees has just retired. Make sure that the retired idmuser04 user is
not able to use any of the company's systems. Retain the retired user data in the domain.
From workstation, use SSH to log in to the idm server as the root user. Use the ipa
user-disable command to disable the idmuser04 user.

[root@idm ~]# ipa user-disable idmuser04

---------------------------------
Disabled user account "idmuser04"
---------------------------------

Evaluation
From workstation, run the lab users-review grade command to confirm the success of
this exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab users-review grade

Cleanup
From workstation, run the lab users-review cleanup command to clean up this exercise.

[student@workstation ~]$ lab users-review cleanup

This concludes the lab.

296 RH362-RHEL-7.4-en-1-20181003
CHAPTER 6 | Controlling User Access

SUMMARY

In this chapter, you learned:

• Life-cycle administrative tasks, such as creating users and changing passwords, can be
delegated to a non-administrative user by defining access controls. Role-based access controls
(RBAC) can be defined and assigned to groups, allowing members to conduct specific life-cycle
management tasks by granting them rights to edit, add, and delete user and group attributes.

• Host-based access control (HBAC) rules can be defined to limit access to specified systems in
your domain to members of a specific user group. Additionally, an HBAC rule can be defined to
allow only a specific service to be used to access the systems in your domain.

• Identity Management provides a mechanism to consistently apply sudo policies across the IdM
domain. Any system in the IdM domain can be configured as a sudo client.

• IdM supports a Kerberos single sign-on (SSO) method of authentication. Using SSO allows users
who log in to a system successfully once access to multiple services and applications without
having to repeat the process of entering their credentials.

• Two-factor authentication (2FA) is an authentication mechanism that requires you to provide

a combination of two forms of information to authenticate to a service, application, or system.
For example, a random password token that is valid for only one authentication session can be
used as one form and a personal identification number (PIN) can be used as the second form to
complete the two-factor authentication requirements.

• Different mechanisms for Kerberos authentication in IdM can be represented by different

authentication strengths. Critical services or systems can be configured to require strong
authentication, such as two-factor authentication. Noncritical services, such as local logins,
can be configured to allow authentication using a weaker, but more convenient authentication
method such as a user's password that only requires adherence to a basic password policy.

RH362-RHEL-7.4-en-1-20181003 297
298 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7

MAINTAINING IDM
OPERATIONS
GOAL Troubleshoot and recover Identity Management.

OBJECTIVES • Manage the DNS server component of IdM and

integrate with external DNS servers.
• Describe various troubleshooting techniques for
resolving authentication issues.

SECTIONS • Identifying the DNS Configuration (and Guided

Exercise)
• Troubleshooting IdM Activities (and Guided
Exercise)

LAB Lab: Maintaining IdM Operations

RH362-RHEL-7.4-en-1-20181003 299
CHAPTER 7 | Maintaining IdM Operations

IDENTIFYING THE DNS CONFIGURATION

OBJECTIVES
After completing this section, students should be able to:

• Describe integrated DNS server configuration.

• Describe requisite records for maintaining IdM installation.

• Describe secure IdM communications.

INTEGRATED DNS SERVER CONFIGURATION

An IdM server can be installed with an integrated DNS service. Such a deployment offers a
significant level of flexibility and control over DNS settings. For example, clients can update their
own DNS records dynamically, and all DNS entries can be managed using native IdM tools. The
majority of configuration options work the same way in both BIND and IdM. Most configuration
options applicable to BIND version 9.9 are also applicable to IdM DNS.

IdM integrates BIND DNS server (9.9) with an LDAP database used for replication and with
Kerberos for DNS update signing. This type of integration enables DNS management in a
convenient way using IdM tools, and at the same time increases the availability and security of the
environment.

NOTE
If you ran the ipa-server-install command without DNS configuration, you can
still configure DNS by running the ipa-dns-install command.

If the IdM DNS server is accessible from the public Internet, Red Hat recommends hardening
the BIND service as described in the Red Hat Enterprise Linux Networking Guide at https://
access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/.

NOTE
The default IdM DNS configuration is suitable for internal networks. It is not possible
to run IdM-integrated BIND inside a chroot environment.

The integrated BIND server uses the bind-dyndb-ldap plug-in to communicate with the
Directory Server. In the /etc/named.conf BIND configuration file, IdM creates a dynamic-db
section, which configures the plug-in for the BIND service.

[root@demo ~]# cat /etc/named.conf

...output omitted...
dyndb "ipa" "/usr/lib64/bind/ldap.so" {
uri "ldapi://%2fvar%2frun%2fslapd-DEMO-EXAMPLE-NET.socket";
base "cn=dns, dc=demo,dc=example,dc=com";
server_id "idm.demo.example.com";
auth_method "sasl";
sasl_mech "GSSAPI";
sasl_user "DNS/idm.demo.example.com";

300 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

...output omitted...

IdM stores all DNS information as LDAP entries. Every resource record is stored as an LDAP
attribute of an LDAP entry. The following is an example of such an LDAP record:

dn: idnsname=demo,idnsname=example.com.,cn=dns,dc=idm,dc=example,dc=com

objectclass: top
objectclass: idnsrecord
idnsname: demo
Arecord: 192.168.1.1
AAAArecord: 2001:DB8::ABCD

IdM Required DNS Records

IdM with integrated DNS dynamically updates its own DNS records after any change. Those
changes can also be executed by using the ipa dns-update-system-records command.

The list of all required DNS resource records can be accessed using the ipa dns-update-
system-records --dry-run command.

The following output shows a real example of required DNS records for an IdM server without any
additional replicas:

[root@demo ~]# ipa dns-update-system-records --dry-run

IPA DNS records:
_kerberos-master._tcp.lab.example.net. 86400 IN SRV 0 100 88
idm.lab.example.net.
_kerberos-master._udp.lab.example.net. 86400 IN SRV 0 100 88
idm.lab.example.net.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.lab.example.net. 86400
IN SRV 0 100 88 idm.lab.example.net.
_kerberos._tcp.dc._msdcs.lab.example.net. 86400 IN SRV 0 100 88
idm.lab.example.net.
_kerberos._tcp.lab.example.net. 86400 IN SRV 0 100 88 idm.lab.example.net.
_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.lab.example.net. 86400
IN SRV 0 100 88 idm.lab.example.net.
_kerberos._udp.dc._msdcs.lab.example.net. 86400 IN SRV 0 100 88
idm.lab.example.net.
_kerberos._udp.lab.example.net. 86400 IN SRV 0 100 88 idm.lab.example.net.
_kerberos.lab.example.net. 86400 IN TXT "LAB.EXAMPLE.NET"
_kpasswd._tcp.lab.example.net. 86400 IN SRV 0 100 464 idm.lab.example.net.
_kpasswd._udp.lab.example.net. 86400 IN SRV 0 100 464 idm.lab.example.net.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.lab.example.net. 86400 IN
SRV 0 100 389 idm.lab.example.net.
_ldap._tcp.dc._msdcs.lab.example.net. 86400 IN SRV 0 100 389
idm.lab.example.net.
_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 idm.lab.example.net.
_ntp._udp.lab.example.net. 86400 IN SRV 0 100 123 idm.lab.example.net.
ipa-ca.lab.example.net. 86400 IN A 172.25.250.8

RH362-RHEL-7.4-en-1-20181003 301
CHAPTER 7 | Maintaining IdM Operations

DNS Zone Types

IdM supports two DNS zone types: master and forward zones. The master DNS zone contains
authoritative DNS data and accepts dynamic DNS updates. They are managed with the ipa
dnszone-* commands.

IdM generates all required SOA and NS records for every master zone automatically when they are
created. To create a delegation, the NS records must be manually copied to the parent zone.

All queries for names belonging to zones that do not contain any authoritative data are forwarded
to a specified forwarder. Forward zones are managed using the ipa dnsforwardzone-*
commands.

MANAGING DNS ZONES

You can manage DNS using the Web UI or the CLI.

To manage a master DNS zone using the Web UI follow this procedure:

1. Log in to the Web UI. Go to Network Services tab, and select DNS → DNS Zones.

Figure 7.1: Managing DNS Zones

2. To add a new master zone, click the Add.

3. In the Add DNS Zone dialog window, type in the zone name and click the Add button.

Figure 7.2: Adding a Master DNS Zones

Adding Master DNS Zone from the Command Line

To add a new master DNS zone using the command-line interface, use the ipa dnszone-add
command. When adding a new zone, it is required to specify the zone's new name. You can pass the
domain or subdomain name directly with the command:

302 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

[root@demo ~]# ipa dnszone-add new.domain.com

The script prompts for the domain name automatically when the name has not been specified.

Removing the Master DNS Zone

To remove an existing master DNS zone using the Web UI, go to Network Services tab, and select
DNS → DNS Zones. From the list of all zones, select the checkbox next to the name of the zone
you want to remove and click the Delete button.

Figure 7.3: Choosing a Master DNS Zones

When the Remove DNS Zones window pops out, confirm the removal by clicking the Delete button.

Figure 7.4: Removing a Master DNS Zones

To remove a master DNS zone from the command line, use the ipa dnszone-del command.

[root@demo ~]# ipa dnszone-del zone.example.com

ADDITIONAL CONFIGURATION FOR MASTER DNS

ZONES
When deployed, IdM creates a new DNS zone with a certain default configuration defining
attributes such as the refresh periods, transfer settings, or cache settings. You can edit the zone
configuration in the Web UI. To do so, open the Network Services tab and select DNS → DNS
Zones section.

1. Click the appropriate zone name in the list of all zones.

2. Click the Settings tab, and make the required changes.

RH362-RHEL-7.4-en-1-20181003 303
CHAPTER 7 | Maintaining IdM Operations

Figure 7.5: Editing a Master DNS Zones

3. To confirm and activate the changes, click the Save button.

Editing the Zone Conﬁguration from the Command Line

An existing master DNS zone can be modified from the command line with the ipa dnszone-
mod command. If an attribute does not exist, the ipa dnszone-mod command adds the attribute.
Otherwise, the command overwrites the current value with the newly specified value.

This example demonstrates how to enable dynamic updates for a zone:

[root@demo ~]# ipa dnszone-mod demo.domain.com --dynamic-update=TRUE

ADDING RECORDS TO DNS ZONE

IdM's internal DNS supports many different record types. The most frequently used record types
are:

• A records map the hostname and the IPv4 address. The name of an A record is a host name (for
example: www, or ftp). The IP Address value of this record is a standard IPv4 address.

• SRV records map service names to the name of the server that is providing the service. When
you deploy a new IdM server with integrated DNS, this record is automatically created to map
the LDAP directory service to the server which manages it. The record name has the format
_service._protocol., for example, _ldap._tcp. The record can include options such as priority,
weight, port number, and hostname for the target service.

• PTR records are used in reverse DNS zones to map an IP address to a domain name.

Adding DNS Resource Records from the Web UI

Different DNS resource records require different data. For this reason, the Web UI interface is
probably the better choice when adding new records to your DNS zones. In the Web UI, the fields in

304 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

the form for adding a new record are updated automatically to reflect what data is required for the
selected type of record to add.

To add a new DNS Resource Record using the Web UI, follow this procedure:

1. To find and edit the zone configuration in the Web UI, open the Network Services tab, and
select DNS → DNS Zones section.

2. Click the appropriate zone name in the list of all zones.

3. Click the Settings tab, and make the required changes.

4. Click the Add button.

5. A new Add DNS Resource Record dialog window pops out. Select the appropriate type of
record you want to create and fill out all the required fields.

Figure 7.6: Adding a new DNS resource record

6. Click the Add button to confirm and add the new record.

Adding DNS Resource Records from the Command Line

To add a DNS resource record from the command line, use the ipa dnsrecord-add command.
The command uses the following syntax:

[root@demo ~]# ipa dnsrecord-add new.domain.com record_name --

record_type_option=data

The following example demonstrates how to create a new A type record for the
www.demo.example.com host:

[root@demo ~]# ipa dnsrecord-add demo.example.com www --a-rec 192.168.1.11

For more details on how to use ipa dnsrecord-add, run the ipa dnsrecord-add --help
command.

DELETING RECORDS FROM DNS ZONES

To delete a specific record type using the Web UI:

1. To find and edit the zone configuration in the Web UI, open the Network Services tab, and
select DNS → DNS Zones section.

RH362-RHEL-7.4-en-1-20181003 305
CHAPTER 7 | Maintaining IdM Operations

2. Click the appropriate zone name in the list of all zones.

3. Click the Settings tab and make the required changes.

4. In the DNS Resource Records section, find and click the name of the resource you want to
remove.

Figure 7.7: Deleting a DNS resource record

5. Select the check box next to the name of the record type to delete. This activates the Delete
button. Once it is active, click it to remove the selected resource type.

Deleting Records from the Command Line

To remove records from a zone using the command line, use the ipa dnsrecord-del command.
The following example shows how to remove the A type record:

[root@demo ~]# ipa dnsrecord-del demo.example.net ftp --a-rec 192.168.1.11

When used without any options, the ipa dnsrecord-del command prompts for information
about the record to delete.

MANAGING DYNAMIC DNS UPDATES

By default, the dynamic updates are disabled in IdM. When registering new hosts in IdM, the ipa-
client-install command cannot add a DNS record pointing to the new host.

Dynamic DNS updates pose a security risk. However, if it is acceptable in your environment, they
make the client installations easier. To enable dynamic updates in your environment, you must
change the following settings:

• The DNS zone must allow dynamic updates.

• The local clients must be able to send dynamic updates.

Enabling Dynamic DNS Updates

To enable dynamic DNS updates in the Web UI, follow this procedure:

1. Edit the zone configuration in the Web UI. Open the Network Services tab, and select DNS →
DNS Zones section.

2. Click the appropriate zone name in the list of all zones.

3. Click the Settings tab.

4. Scroll down to the Dynamic update field, and set the value to True.

306 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

Figure 7.8: Managing DNS zones

5. Scroll up to the top of the page and click the Save button to confirm the change.

Enabling Dynamic DNS Updates from the Command Line

To enable the dynamic DNS updates from the command line, use the ipa dnszone-mod
command with the --dynamic-update=TRUE option.

[root@demo ~]# ipa dnszone-mod new.domain.com --dynamic-update=TRUE

When enrolling new clients in the domain, use the --enable-dns-updates option to set up the
DNS dynamic updates automatically.

[root@client ~]# ipa-client-install --enable-dns-updates

REFERENCES
Further information is available in the chapter on Administration: Managing Network
Services in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-US/index.html

RH362-RHEL-7.4-en-1-20181003 307
CHAPTER 7 | Maintaining IdM Operations

GUIDED EXERCISE

IDENTIFYING THE DNS CONFIGURATION

In this exercise, you will view, delete, and recreate DNS records.

OUTCOMES
You should be able to view, delete and add DNS records.

Log in to workstation as student using student as the password. Run the lab maintain-
dns setup command to configure the environment.

[student@workstation ~]$ lab maintain-dns setup

1. From workstation, open a new terminal and log in to the idm server as the student user,
then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

2. Run the kinit admin command to log in to the IPA server. When prompted, use
RedHat123^ as password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3. Use the ipa dnsserver-find command to ensure that your IdM server is installed and
configured with the internal DNS.

[root@idm ~]# ipa dnsserver-find

--------------------
1 DNS server matched
--------------------
Server name: idm.lab.example.net
SOA mname override: idm.lab.example.net.
Forward policy: only
----------------------------
Number of entries returned 1
----------------------------

4. Use the ipa dnsforwardzone-find command to display the DNS forwarder records.

[root@idm ~]# ipa dnsforwardzone-find

Zone name: example.net.
Active zone: TRUE

308 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

Zone forwarders: 172.25.250.13

Forward policy: only
----------------------------
Number of entries returned 1
----------------------------

5. Use the ipa dnsrecord-find command to display all records in the lab.example.net
domain.

[root@idm ~]# ipa dnsrecord-find

Zone name: lab.example.net
Record name: @
NS record: idm.lab.example.net.

Record name: _kerberos

TXT record: "LAB.EXAMPLE.NET"

Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs

SRV record: 0 100 88 idm.lab.example.net.

Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs

SRV record: 0 100 389 idm.lab.example.net.

Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kerberos._tcp.dc._msdcs

SRV record: 0 100 88 idm.lab.example.net.

Record name: _ldap._tcp.dc._msdcs

SRV record: 0 100 389 idm.lab.example.net.

Record name: _kerberos._udp.dc._msdcs

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kerberos._tcp

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kerberos-master._tcp

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kpasswd._tcp

SRV record: 0 100 464 idm.lab.example.net.

Record name: _ldap._tcp

SRV record: 0 100 389 idm.lab.example.net.

Record name: _kerberos._udp

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kerberos-master._udp

SRV record: 0 100 88 idm.lab.example.net.

Record name: _kpasswd._udp

SRV record: 0 100 464 idm.lab.example.net.

RH362-RHEL-7.4-en-1-20181003 309
CHAPTER 7 | Maintaining IdM Operations

Record name: _ntp._udp

SRV record: 0 100 123 idm.lab.example.net.

Record name: client

A record: 172.25.250.11
SSHFP record: 1 1 0E534CC5895C858D5F1CE6ADD6CB9E84CF08DF02, 1 2
48A3DB16A7C3F450BD38E06B683CC32EB5E302A7E644F625F7D0BB0A 7DF36A4D, 3 1
3B48710859AE270840D1A9C633D35C18BE083129, 3 2
9579A9056D2F09F830AD21B36F4A92F4ACC8960D9F4E6A7C93F948B2 E096DB54, 4 1
55CB55287599AEA44B3819727269477C8B43B294, 4 2
95F681EBC584966E0F83BF2BC8CA3AC8D2F7718C599A9138747D74B3 62E18115

Record name: idm

A record: 172.25.250.8
SSHFP record: 1 1 0E534CC5895C858D5F1CE6ADD6CB9E84CF08DF02, 1 2
48A3DB16A7C3F450BD38E06B683CC32EB5E302A7E644F625F7D0BB0A 7DF36A4D, 3 1
3B48710859AE270840D1A9C633D35C18BE083129, 3 2
9579A9056D2F09F830AD21B36F4A92F4ACC8960D9F4E6A7C93F948B2 E096DB54, 4 1
55CB55287599AEA44B3819727269477C8B43B294, 4 2
95F681EBC584966E0F83BF2BC8CA3AC8D2F7718C599A9138747D74B3 62E18115

Record name: ipa-ca

A record: 172.25.250.8
-----------------------------
Number of entries returned 19
-----------------------------

6. Use the ipa dnszone-find command to view all zones that your DNS server maintains.

[root@idm ~]# ipa dnszone-find

Zone name: 25.172.in-addr.arpa.
Active zone: TRUE
Authoritative nameserver: idm.lab.example.net.
Administrator e-mail address: hostmaster.lab.example.net.
SOA serial: 1522827080
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
Allow query: any;
Allow transfer: none;

Zone name: lab.example.net.

Active zone: TRUE
Authoritative nameserver: idm.lab.example.net.
Administrator e-mail address: hostmaster.lab.example.net.
SOA serial: 1522827080
SOA refresh: 3600
SOA retry: 900
SOA expire: 1209600
SOA minimum: 3600
Allow query: any;
Allow transfer: none;
----------------------------

310 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

Number of entries returned 2

----------------------------

7. Use the ipa dnsrecord-del command, to delete the _ldap._tcp record from the
lab.example.net zone.

[root@idm ~]# ipa dnsrecord-del

Record name: _ldap._tcp
Zone name: lab.example.net
No option to delete specific record provided.
Delete all? Yes/No (default No): Enter
Current DNS record contents:

SRV record: 0 100 389 idm.lab.example.net.

Delete SRV record '0 100 389 idm.lab.example.net.'? Yes/No (default No): Yes
---------------------------
Deleted record "_ldap._tcp"
---------------------------

8. Use the ipa dnsrecord-show command to ensure that the _ldap._tcp record has
been removed.

[root@idm ~]# ipa dnsrecord-show

Record name: _ldap._tcp
Zone name: lab.example.net
ipa: ERROR: _ldap._tcp: DNS resource record not found

9. Use the ipa dnsrecord-add command to add the missing record.

[root@idm ~]# ipa dnsrecord-add \

lab.example.net _ldap._tcp \
--srv-rec="0 100 389 idm.lab.example.net."
Record name: _ldap._tcp
SRV record: 0 100 389 idm.lab.example.net.

10. Use the ipa dnsrecord-show command to ensure that the _ldap._tcp record has
been added back.

[root@idm ~]# ipa dnsrecord-show

Record name: _ldap._tcp
Zone name: lab.example.net
Record name: _ldap._tcp
SRV record: 0 100 389 idm.lab.example.net.

Cleanup
From workstation, run the lab maintain-dns cleanup command to clean up this exercise.

[student@workstation ~]$ lab maintain-dns cleanup

RH362-RHEL-7.4-en-1-20181003 311
CHAPTER 7 | Maintaining IdM Operations

This concludes the guided exercise.

312 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

TROUBLESHOOT IDM ACTIVITIES

OBJECTIVES
After completing this section, students should be able to:

• Troubleshoot IdM activities.

• Debug Kerberos principals.

• Query and fix expired certificates.

GENERAL SERVICES TROUBLESHOOTING

When approaching a troubleshooting problem, there are various pieces of information that need to
be collected before a hypothesis can be formed. Not all of this information may be readily available;
sometimes a service needs to be configured to increase the amount of logging it performs, or the
system needs to be configured to store information that would normally be discarded upon reboot.

It is advisable to always check the system logs first, both on the IdM server and the IdM clients.
By default, a Red Hat Enterprise Linux 7 system uses two logging services for the system logs:
systemd-journald, which is configured to only keep logs in memory, and rsyslogd, which gets
messages sent to it by systemd-journald (and others) and stores them on disk.

To view messages in the system journal, a tool called journalctl can be used. If used without
any parameters, it shows the full contents of the system journal, presented in a pager (by default,
less is used). The output of journalctl can be modified by using both options and filters.
Options can be used to change the number of lines displayed, to turn on follow mode, change the
displayed field, specify a time range, and so on. Filters can be used to modify which services, units,
executables, and so on, are shown.

The following example outlines the possible ways of accessing system logs for troubleshooting
problems with the IdM services or the SSSD service:

• journalctl -ef jumps to the end of the journal (-e), and enables follow mode (-f). This
keeps the journal open on screen, displaying new messages as they come in.

• journalctl _SYSTEMD_UNIT=ipa.service displays all messages generated by the

ipa.service systemd unit.

• journalctl -u ipa.service displays all messages generated by, and about, the ipa.service
systemd unit.

• journalctl -p emerg..err displays all messages in the journal with a priority in the range
emerg up to and including err.

• ipa -vvv VERB displays a verbose output. This allows you to obtain more information about
the errors that you are encountering.

For a complete list of options and filters, refer to the journalctl man page.

PROBLEMS WITH SSSD

When users report a problem with logging in to their systems using credentials stored and
maintained by the IdM, the first places to look are the local SSSD service logs. SSSD provides a tool
named sssctl that can be especially useful for troubleshooting.

RH362-RHEL-7.4-en-1-20181003 313
CHAPTER 7 | Maintaining IdM Operations

On the problematic system, install the sssd-tools package.

[root@client ~]# yum install sssd-tools

The sssctl tool used to troubleshoot SSSD uses the SSSD InfoPipe responder to transmit
information from the SSSD over the system bus. Add ifp to the service option of your /etc/
sssd/sssd.conf SSSD configuration file and restart the SSSD service.

[root@client ~]# vim /etc/sssd/sssd.conf

...output omitted...
[sssd]
services = nss, sudo, pam, ssh, ifp
...output omitted...

[root@client ~]# systemctl restart sssd

From now on, you can use the sssctl config-check command to perform an analysis of the
SSSD configuration files. This command validates the /etc/sssd/sssd.conf file and the /etc/
sssd/conf.d/* files.

The sssctl config-check command performs the following checks on the configuration files:

• It verifies correct permissions. File ownership must be set to root:root, and the
permissions to 600.

• It reviews the content of the /etc/sssd/conf.d/ directory. The file names must use the
.conf suffix and they cannot be hidden files (files that start with a dot).

• The configuration file is reviewed for typographical errors in section and option names.

• Options are reviewed for correct placement in the appropriate sections of the configuration file.

To ensure that the configuration file does not contain any errors, run the sssctl config-check
command.

The following provides example output with multiple errors in the SSSD configuration file and the
wrong file type in the /etc/sssd/conf.d directory:

[root@client ~]# sssctl config-check

Issues identified by validators: 2
[rule/allowed_sections]: Section [sUdo] is not allowed. Check for typos.
[rule/allowed_domain_options]: Attribute 'offline_temounts' is not allowed in
section 'domain/lab.example.net'. Check for typos.

Messages generated during configuration merging: 1

File .hidden-config-file.conf did not match provided patterns. Skipping.

Used configuration snippet files: 0

Debug Logs for SSSD

SSSD uses a number of different log files located in the /var/log/sssd directory. Additional
authentication failures and reasons for the failure might be located in the /var/log/secure log
file.

314 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

Should you need more information about the potential problem, you can always increase the
default log level by setting the debug_level parameter for each section in the sssd.conf file.
The following shows an example of setting the parameter to the maximum output value of 9:

[domain/demo.example.net]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = demo.example.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client.demo.example.net
chpass_provider = ipa
ipa_server = _srv_, idm.demo.example.net
ldap_tls_cacert = /etc/ipa/ca.crt
debug_level = 9

The debug level may also be increased to the maximum output level while SSSD is running. To do
this, issue the sss_debuglevel 9 command.

KERBEROS PROBLEMS
Kerberos issues can show up in two ways: users cannot obtain a TGT to log in to servers, and users
or services cannot authenticate to services.

To troubleshoot login issues, start by determining:

• Are the times between all parties synchronized? A time drift of more than two minutes causes
Kerberos to fail.

• Does a kinit username command for a user work from all configured machines? If it works
from some machines but not others, there is a problem with the configuration for authentication,
which can typically be fixed with the SSSD family of tools. If it does not work from any machine,
there might be an issue with the KDC itself, or with the Kerberos configuration files on the
machine.

• Does the default_realm setting, and the mapping of host names to machines in the
domain_realm section of /etc/krb5.conf, match the actual values used in your
environment?

• Are the DNS records for Kerberos correct? Is the DNS server reachable?

• Do the krb5_realm and krb5_server settings in /etc/sssd/sssd.conf match reality?

• The /var/log/secure log file and the journalctl command contains messages regarding
failed logins; do they point to a likely cause?

When users can login but cannot authenticate to certain services, or service-to-service
authentication, like NFSv4, fails, a number of extra things need to be determined.

• Are the services able to read their keytab? For SSH and NFS and other similar services, see /
etc/krb5.keytab. The file to verify depends on the service involved.

• Is the keytab using the most recent version of the password? Keytabs can be inspected with the
klist -ek FILENAME command. The KVNO column shows the version of the password stored.
Whenever a principal is added to a keytab, a new random password is generated automatically.

RH362-RHEL-7.4-en-1-20181003 315
CHAPTER 7 | Maintaining IdM Operations

• Are the correct principals present in the keytab?

• Do services agree on how Kerberos should be used? For example, an NFS export that specifies
sec=krb5p can only be mounted when the client specifies a matching krb5p security level in its
mount options.

• Are all needed helper services running? For example, an NFS server needs the nfs-secure-
server.service service, and an NFS client needs the nfs-secure.service service when
using Kerberos-enabled NFSv4.

Kinit Authentication Failures

When users report problems with requesting Kerberos tickets, start troubleshooting with debug
messages from the kinit command:

[user@client ]$ KRB5_TRACE=/dev/stdout kinit admin

Make sure that the server entries in /etc/hosts file are correct. Verify that the DNS client
configuration in the /etc/resolv.conf file points to the correct DNS server and has the correct
search domain.

Use the host command to run DNS queries for both the client hostname and IP address, as well as
the IdM server hostname and IP address.

On the IdM server, ensure that all required services are running. You can do this by issuing the
ipactl status. For Kerberos-related problems, the krb5kdc and the dirsrv services must be
running.

On the IdM server, review the KDC log file, located at /var/log/krb5kdc.log.

Make sure that DNS discovery is enabled in the /etc/krb5.conf file (dns_lookup_kdc =
true). Use dig to query the SRV records related to Kerberos:

[user@client ~]$ dig -t SRV _kerberos._tcp.demo.example.com

...output omitted...
_kerberos._tcp.demo.example.com. 86400 IN SRV 0 100 88 idm.demo.example.com.
...output omitted...
[user@client ~]$ dig -t SRV _kerberos._udp.demo.example.com
...output omitted...
_kerberos._tcp.demo.example.com. 86400 IN SRV 0 100 88 idm.demo.example.com.
...output omitted...

DEBUGGING SUDO WITH SSSD

When troubleshooting sudo with SSSD, it is recommended to start by enabling the debug logging
feature in the /etc/sudo.conf configuration file.

Enabling the debug feature allows you to gather additional information about SSSD and sudo
in the logs. Debugging is disabled by default, to enable it add the following lines to the /etc/
sudo.conf file:

...output omitted...
Debug sudo /var/log/sudo_debug_file.log all@debug
Debug sudoers.so /var/log/sudo_debug_file.log all@debug
...output omitted...

316 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

Once enabled, run the sudo command as the user that reported the problem. The log file is
automatically created and provides additional information that can help you determine the cause
of the problem, for example:

• Additional information about the user and the environment when running the sudo command.

• The data source of the sudo rules.

• The number of rules that SSSD returned.

• A report about matching rules and those that are designed to match but do not.

Always enable SSSD debugging when investigating problems. The /var/log/sssd/

sssd_domain_name.log domain log file provides additional information, such as:

• The number of rules returned by SSSD

• A list of rules downloaded by SSSD

• Filters used to download the rules

• Whether the rules are stored successfully in cache

IDENTITY MANAGEMENT LOG FILES

Many potential problems occur during reconfiguration of IdM components. To quickly find a
potential cause of problems, the following log files located in the /var/log/ directory on the IdM
server might be helpful:

• /var/log/ipaserver-install.log contains the installation log for the IdM server.

• /var/log/ipareplica-install.log contains the installation log for the IdM replica.

• /var/log/ipaclient-install.log contains the installation log for the IdM client.

• /var/log/httpd/ contains log files for the Apache web server used by the IdM.

• /var/log/pki/ contains the logs related to the PKI operations, IdM CA, and KRA.

• /var/log/dirsrv/ contains logs related to the Directory Server instance used by the IdM
server.

HANDLING EXPIRED CERTIFICATES

Part of the machine authentication process is managing machine certificates. IdM's included
Certificate Authority (CA) works together with the certmonger service on the clients. If there
is a problem due to expired certificates, use the getcert list command on a server to list all
certificates monitored by the certmonger service.

The following example shows the status of a certificate monitored by certmonger:

[root@demo ~]# getcert list

RH362-RHEL-7.4-en-1-20181003 317
CHAPTER 7 | Maintaining IdM Operations

principal name: krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET

key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes

All monitored certificates should be automatically renewed before they expire. Should you need
to manually request a new certificate from the CA, use the getcert command to stop tracking an
existing certificate and to request a new one.

The following shows an example of removing an expired certificate and requesting a new one with
the use of the getcert:

1. On the server with the expired certificate, run the getcert list command to list all
available certificates:

[root@demo ~]# ipa-getcert list

Request ID '20180420065500':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/tower.key'
certificate: type=FILE,location='/etc/tower.crt'
CA: IPA
issuer: CN=Certificate Authority,O=DEMO.EXAMPLE.NET
subject: CN=idm.lab.example.net,O=DEMO.EXAMPLE.NET
expires: 2020-04-20 06:55:01 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
track: yes
auto-renew: yes

2. Once you have identified the expired certificate, use its Request ID from the ipa-getcert
list output as an argument for the getcert command, to remove the certificate:

[root@demo ~]# ipa-getcert stop-tracking -i 20180420065500

Request "20180420065500" removed.

3. To request a fresh certificate from the IdM server, use the ipa-getcert request command
and specify the location for the certificate and key:

[root@demo ~]# ipa-getcert request -f /PATH/TO/THE/file.cert - k /PATH/TO/THE/

file.key -r
New signing request "20180425143522" added.

REFERENCES
Further information is available in the chapter on Troubleshooting: Solutions to
Specific Problems in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html-single/linux_domain_identity_authentication_and_policy_guide/#trouble-
specific

318 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

GUIDED EXERCISE

TROUBLESHOOTING IDM ACTIVITIES

In this exercise, you will query and fix expired certificates.

OUTCOMES
You should be able to query and fix expired IdM certificates.

Log in to workstation as student using student as the password. Run the lab maintain-
trouble setup command to configure the environment.

[student@workstation ~]$ lab maintain-trouble setup

1. From workstation, open a new terminal and log in to the idm server as the student user,
then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

2. In the following steps, you simulate the expiration of the IdM certificates. This operation
stops various IdM components from working, which allows you to explore the environment
in search of the cause of the failure.
2.1. Use the getcert list command to list all certificates monitored by the
certmonger service.

[root@idm ~]# getcert list

...output omitted...
Request ID '20180405113457':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: IPA
issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
subject: CN=idm.lab.example.net,O=LAB.EXAMPLE.NET
expires: 2020-04-05 11:34:58 UTC
principal name: krbtgt/LAB.EXAMPLE.NET@LAB.EXAMPLE.NET
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes

RH362-RHEL-7.4-en-1-20181003 319
CHAPTER 7 | Maintaining IdM Operations

auto-renew: yes

Notice the expiry date for all the different certificates. Most of the certificates are
valid for two years.
2.2. Use the systemctl stop ntpd command to stop the NTP service.

[root@idm ~]# systemctl stop ntpd

2.3. Use the date MMDDHHMMYYYY command to change the date so that the certificates
expire; for example, set it to at least two years and 1 month from today's date.

[root@idm ~]# date 053012022021

Sun May 30 12:02:00 EDT 2021

2.4. Use the ipactl restart command to restart IdM services. Some of the services
fail to start because of the expired certificates.

[root@idm ~]# ipactl restart

Stopping pki-tomcatd Service
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Failed to restart httpd Service
Shutting down
Hint: You can use --ignore-service-failure option for forced start in case that a
non-critical service failed
Aborting ipactl

Leave the IdM terminal window open and proceed to the next step.

3. On workstation, open Firefox and try to access the IdM web UI at http://
idm.lab.example.net.
You are presented with the Unable to connect message.

4. To fix this problem, you need to investigate what exactly caused the failure of the IdM
services. You should always start with accessing the services log files.
4.1. On the idm.lab.example.net server, access the directory server error log file
under the /var/log/dirsrv/slapd-LAB-EXAMPLE-NET/ directory. Search for
errors or warnings.

[root@idm ~]# tail -n 50 /var/log/dirsrv/slapd-LAB-EXAMPLE-NET/errors |grep WARN

[30/May/2021:12:02:12.038650968 -0400] - WARN - Security Initialization - SSL
alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert
of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 -
Peer's Certificate has expired.)

320 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

[30/May/2021:12:02:12.068811493 -0400] - WARN - default_mr_indexer_create - Plugin

[caseIgnoreIA5Match] does not handle caseExactIA5Match

Notice the SSL warning about the expired certificate. When the certificates expire,
different IdM services are configured to fail. This is designed to prevent a domain
controller from running with expired certificates.
4.2. Access the last 50 lines of the httpd service error_log file, located in the /var/
log/httpd/ directory.

[root@idm ~]# tail -n 50 /var/log/httpd/error_log

...output omitted...
[Sun May 30 12:02:15.187700 2021] [:error] [pid 10593] SSL Library Error: -8181
Certificate has expired
[Sun May 30 12:02:15.187718 2021] [:error] [pid 10593] Unable to verify
certificate 'Server-Cert'. Add "NSSEnforceValidCerts off" to nss.conf so the
server can start until the problem can be resolved.

Notice the SSL error about the expired certificate. This caused the httpd service to
fail.

5. In a real world scenario, the solution to fix this problem would be to generate and sign new
certificates. In this case, to fix the problem and start IdM without the errors, you have to set
the correct date and time on the idm.lab.example.net server.
5.1. Use the ntpdate -u command to set the correct date and time
on the idm.lab.example.net server. As the time source use the
classroom.example.com server IP address of 172.25.254.254.

[root@idm ~]# ntpdate -u 172.25.254.254

5 Apr 10:26:09 ntpdate[10989]: step time server 172.25.254.254 offset
-99455842.277038 sec

5.2. Use the ipactl start command to start IdM services.

[root@idm ~]# ipactl restart

Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting smb Service
Starting winbind Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

5.3. Use the ipactl status command to verify that all IdM services are running.

[root@idm ~]# ipactl status

Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING

RH362-RHEL-7.4-en-1-20181003 321
CHAPTER 7 | Maintaining IdM Operations

named Service: RUNNING

httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

Cleanup
From workstation, run the lab maintain-trouble cleanup command to clean up this
exercise.

[student@workstation ~]$ lab maintain-trouble cleanup

This concludes the guided exercise.

322 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

LAB

MAINTAINING IDM OPERATIONS

PERFORMANCE CHECKLIST
In this lab, you will fix important configuration records for IdM.

OUTCOMES
You should be able to fix all errors and start all IdM services.

Log in to workstation as student using student as the password. Run the lab maintain-
review setup command to configure the environment.

[student@workstation ~]$ lab maintain-review setup

IdM services are not running. Investigate the problem and fix it. The problem is resolved when you
are able to request a Kerberos ticket for the admin user on the client server. Users from IdM as
well as from Active Directory must also be able to log in to the client system. Use the following
information to fix the issue:

IDM SERVER VALUE

IP Address 172.25.250.8

FQDN idm.lab.example.net

DNS resolver 127.0.0.1 or 172.25.250.8

DNS search domain lab.example.net

/etc/hosts entry 172.25.250.8 idm.lab.example.net idm

1. From workstation use SSH to log in to the client system as the student user. If needed,
use the sudo -i command to escalate privileges. Request a Kerberos ticket for the admin
user, use RedHat123^ as password.
2. On the IdM server, verify that all the required IdM services are running. Log in to the server as
the student user and use the sudo -i command to escalate privileges.
3. If necessary, use the log file to determine the cause of the issue.
4. Verify that the IdM server DNS client configuration points to the local DNS and has the proper
search domain defined. Make sure that the network interface configuration file has the proper
DNS setting.
5. Verify the IPv4 configuration of the IdM system.
6. Verify that the necessary IPv4 host entry exists in the /etc/hosts file.
7. Restart IdM services and verify that all are running.
8. Verify that IdM can resolve the _ldap._tcp records for both example.net and
lab.example.net domains.

RH362-RHEL-7.4-en-1-20181003 323
CHAPTER 7 | Maintaining IdM Operations

9. On the idm server, request a Kerberos ticket for the admin user, use RedHat123^ as
password.
10. On the IdM server, request a Kerberos ticket for the aduser04@example.net Active
Directory user, use RedHat123^ as password.
11. On the client server, request a Kerberos ticket for the aduser04@example.net Active
Directory user. Use RedHat123^ as the password.
12. Log in using SSH from workstation to the client system as the idmuser04 user as well
as the aduser04@client user. Both users must be able to log in.

Evaluation
From workstation, run the lab maintain-review grade command to confirm the success
of this lab. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab maintain-review grade

Cleanup
From workstation, run the lab maintain-review cleanup command to clean up this lab.

[student@workstation ~]$ lab maintain-review cleanup

This concludes the lab.

324 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

SOLUTION

MAINTAINING IDM OPERATIONS

PERFORMANCE CHECKLIST
In this lab, you will fix important configuration records for IdM.

OUTCOMES
You should be able to fix all errors and start all IdM services.

Log in to workstation as student using student as the password. Run the lab maintain-
review setup command to configure the environment.

[student@workstation ~]$ lab maintain-review setup

IDM SERVER VALUE

IP Address 172.25.250.8

FQDN idm.lab.example.net

DNS resolver 127.0.0.1 or 172.25.250.8

DNS search domain lab.example.net

/etc/hosts entry 172.25.250.8 idm.lab.example.net idm

1. From workstation use SSH to log in to the client system as the student user. If needed,
use the sudo -i command to escalate privileges. Request a Kerberos ticket for the admin
user, use RedHat123^ as password.
On the client server use the kinit command, request a Kerberos ticket for the admin
user, when prompted type in RedHat123^ as password.

[root@client ~]# kinit admin

kinit: Cannot find KDC for realm "LAB.EXAMPLE.NET" while getting initial
credentials

2. On the IdM server, verify that all the required IdM services are running. Log in to the server as
the student user and use the sudo -i command to escalate privileges.
On the idm server use the kinit command, request a Kerberos ticket for the admin user,
when prompted type in RedHat123^ as password. Use the ipactl status command to
verify the status of IdM services.

[root@idm ~]# kinit admin

RH362-RHEL-7.4-en-1-20181003 325
CHAPTER 7 | Maintaining IdM Operations

kinit: Cannot find KDC for realm "LAB.EXAMPLE.NET" while getting initial
credentials
[root@idm ~]# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other services
ipa: INFO: The ipactl command was successful

3. If necessary, use the log file to determine the cause of the issue.
As indicated by the IdM log files, the host name is not in FQDN format, therefore prevents the
service from starting. Use the hostnamectl command to set the FQDN for the server.

[root@idm ~]# hostname

idm
[root@idm ~]# hostnamectl set-hostname idm.lab.example.net
[root@idm ~]# hostname
idm.lab.example.net

4. Verify that the IdM server DNS client configuration points to the local DNS and has the proper
search domain defined. Make sure that the network interface configuration file has the proper
DNS setting.
Ensure that the entries in /etc/resolv.conf point correctly to the local DNS of either
127.0.0.1 or 172.25.250.8. Ensure that the search domain is set to lab.example.net.
Use the nmcli command with the connection modify ipv4.dns 127.0.0.1 option to
set the correct DNS server.

[root@idm ~]# cat /etc/resolv.conf

# Generated by NetworkManager
search lab.example.net example.net
nameserver 172.25.250.254
[root@idm ~]# vim /etc/resolv.conf
# Generated by NetworkManager
search lab.example.net
nameserver 172.25.250.8
[root@idm ~]# nmcli connection modify "System eth0" ipv4.dns 127.0.0.1
[root@idm ~]# nmcli connection reload "System eth0"

5. Verify the IPv4 configuration of the IdM system.

[root@idm ~]# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 52:54:00:00:fa:08 brd ff:ff:ff:ff:ff:ff
inet 172.25.250.8/24 brd 172.25.250.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe00:fa08/64 scope link
valid_lft forever preferred_lft forever

326 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

6. Verify that the necessary IPv4 host entry exists in the /etc/hosts file.
Ensure that there is an entry mapping the idm.lab.example.net host to its IP address,
172.25.250.8.

[root@idm ~]# grep -w $(hostname) /etc/hosts

[root@idm ~]# vim /etc/hosts
...output omitted...
172.25.250.7 satellite.lab.example.net satellite
172.25.250.8 idm.lab.example.net idm
172.25.250.9 replica1.lab.example.net replica1
172.25.250.10 replica2.lab.example.net replica2
...output omitted...
[root@idm ~]# grep -w $(hostname) /etc/hosts
172.25.250.8 idm.lab.example.net idm

7. Restart IdM services and verify that all are running.

Restart IdM services.

[root@idm ~]# ipactl restart

Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting smb Service
Starting winbind Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

8. Verify that IdM can resolve the _ldap._tcp records for both example.net and
lab.example.net domains.
Make a SRV type query for the _ldap._tcp record in both example.net and
lab.example.net domains.

[root@idm ~]# dig SRV _ldap._tcp.lab.example.net

...output omitted...
;; AUTHORITY SECTION:
lab.example.net. 86400 IN NS idm.lab.example.net.

;; ADDITIONAL SECTION:
idm.lab.example.net. 1200 IN A 172.25.250.8
...output omitted...
[root@idm ~]# dig SRV _ldap._tcp.example.net
...output omitted...
;; ANSWER SECTION:
_ldap._tcp.example.net. 275 IN SRV 0 100 389 ad.example.net.

;; ADDITIONAL SECTION:
ad.example.net. 3391 IN A 172.25.250.13
...output omitted...

RH362-RHEL-7.4-en-1-20181003 327
CHAPTER 7 | Maintaining IdM Operations

9. On the idm server, request a Kerberos ticket for the admin user, use RedHat123^ as
password.
On the idm server use the kinit command, request a Kerberos ticket for the admin user,
when prompted type in RedHat123^ as password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

10. On the IdM server, request a Kerberos ticket for the aduser04@example.net Active
Directory user, use RedHat123^ as password.
On the IdM server use the kinit command. Request a Kerberos ticket for the
aduser04@example.net user. When prompted, type in RedHat123^ as the password.

[root@idm ~]# kinit aduser04@example.net

Password for aduser04@EXAMPLE.NET: RedHat123^

11. On the client server, request a Kerberos ticket for the aduser04@example.net Active
Directory user. Use RedHat123^ as the password.
On the client server use the kinit command to request a Kerberos ticket for the
aduser04@example.net user. When prompted, enter RedHat123^ as the password.

[root@client ~]# kinit aduser04@example.net

Password for aduser04@EXAMPLE.NET: RedHat123^

12. Log in using SSH from workstation to the client system as the idmuser04 user as well
as the aduser04@client user. Both users must be able to log in.
From workstation, open a terminal. Using SSH, log in to the client system as the
idmuser04, followed by the aduser04.

[student@workstation ~]# ssh idmuser04@client

-sh-4.2$ logout
Connection to client closed.
[student@workstation ~]# ssh aduser04@client
Creating home directory for aduser04.
Last failed login: Mon Apr 9 09:14:07 EDT 2018 from 172.25.250.254 on ssh:notty
-sh-4.2$ logout
Connection to client closed.

Evaluation
From workstation, run the lab maintain-review grade command to confirm the success
of this lab. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab maintain-review grade

Cleanup
From workstation, run the lab maintain-review cleanup command to clean up this lab.

[student@workstation ~]$ lab maintain-review cleanup

This concludes the lab.

328 RH362-RHEL-7.4-en-1-20181003
CHAPTER 7 | Maintaining IdM Operations

SUMMARY

In this chapter, you learned:

• IdM can be installed with an integrated DNS service, providing flexibility and control over DNS
settings. IdM stores all DNS information as LDAP entries. Every resource record is stored as an
LDAP attribute of an LDAP entry.

• For security reasons, dynamic DNS updates are disabled by default.

• When the users report a problem with logging in to their systems using credentials stored and
maintained by IdM, the first place to look are local SSSD service logs. SSSD provides an utility
that can be especially useful for troubleshooting.

• IdM supports two DNS zone types: master and forward zones. The master DNS zone contains
authoritative DNS data and accepts dynamic DNS updates. They are managed using the ipa
dnszone-* commands.

All queries for names belonging to zones that do not contain any authoritative data
are forwarded to a specified forwarder. Forward zones are managed using the ipa
dnsforwardzone-* commands.

RH362-RHEL-7.4-en-1-20181003 329
330 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8

INTEGRATING RED HAT

PRODUCTS WITH IDM
GOAL Configure major services to share the IdM
authentication database.

OBJECTIVES • Create and configure centrally managed home

directories for Identity Management users.
• Configure Satellite Server to use IdM as its
authentication engine and store.
• Configure Ansible Tower server to use IdM as its
authentication engine and store.

SECTIONS • Configuring Roaming Home Directories (and

Guided Exercise)
• Integrating Satellite 6 with IdM (and Guided
Exercise)
• Integrating Ansible Tower with IdM (and Guided
Exercise)

LAB Integrating Red Hat Products with IdM

RH362-RHEL-7.4-en-1-20181003 331
CHAPTER 8 | Integrating Red Hat Products With IdM

CONFIGURING ROAMING HOME

DIRECTORIES

OBJECTIVES
After completing this section, students should be able to:

• Describe the components of Linux authentication.

• Configure different types of automount configuration maps.

• Create and configure a user's roaming home directory.

AUTOMOUNT AND AUTOFS

The autofs service automates mounting of directories, as needed, by directing the automount
daemon to mount directories when they are accessed. In addition, after a period of inactivity,
autofs directs automount to unmount auto-mounted directories. Unlike static mounting, on-
demand mounting saves on system resources.

Automount Conﬁguration
On a system utilizing autofs, the automount configuration resides in several different files. The
primary automount configuration file is /etc/auto.master, which contains the master mapping
of automount mount points, and their associated resources, on a system. This mapping is known as
automount maps.

The /etc/auto.master configuration file contains the master map. It can contain references to
other maps. These maps can either be direct or indirect. Direct maps use absolute path names for
their mount points, while indirect maps use relative path names.

Conﬁguring Automount and IdM

While automount typically retrieves its map data from the local /etc/auto.master and
associated files, it can also retrieve map data from other sources. One common source is an LDAP
server.

When a system utilizing autofs is a client in an IdM domain, the automount configuration
no longer resides in local configuration files. Instead, the autofs configuration, such as
maps, locations, and keys, are stored as LDAP entries in the IDM directory. For example, for
the lab.example.net IdM domain, the configuration resides would reside under: dn:
automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com.

IMPLEMENTING ROAMING IDM USER HOME

DIRECTORIES
The storing of automount maps in IdM directory provides the benefit of centralized storage
and administration of automount configurations. By using autofs for on-demand mounting of
Kerberized NFS shares, you can provide IdM users access to their home directories centralized
on an NFS share. This combination effectively creates roaming user home directories, allowing
each IdM user to log into various systems while having access to their centralized home directory
instance.

The implementation of roaming home directories for IdM users require the configuration of several
components.

332 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

IdM Automount Maps

Define and store automount configuration in the IdM directory.

NFS Server
Configure an NFS server with a share to house the home directories of IdM users. The NFS server
must be a client of the IdM domain. The NFS server service needs to be Kerberos-aware.

NFS Client
The NFS client where the roaming home directory will be accessed must also be a client of the IdM
domain. In order to access the share on the Kerberos-aware NFS server, the NFS client must be
Kerberos-aware.

CONFIGURING NFS SERVER

The following steps outline the process for configuring an IdM client as a Kerberos-aware NFS
server for roaming IdM user home directories.

1. Create a service principal for the NFS service.

2. Generate, retrieve, and install the NFS service keytab to the /etc/krb5.keytab.

3. Install the nfs-utils package to implement the NFS service.

4. Configure firewall access to the NFS service.

5. Configure support for NFS clients that utilize older encryption options by adding the
allow_weak_crypto = true entry into /etc/krb5.conf. Also, use the ldapmodify
command to update the IdM server's Kerberos configuration to support older DES encryption
options.

[root@idmserver ~]# ldapmodify -x -D "cn=Directory Manager" -w RedHat123^ -h

idm.lab.example.net -p 389 <<EOF
dn: cn=lab.example.net,cn=kerberos,dc=lab,dc=example,dc=net
changetype: modify
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:normal
-
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:special
-
add: krbDefaultEncSaltTypes
krbDefaultEncSaltTypes: des-cbc-crc:special
EOF

6. Execute the ipa-client-automount command to enable secure NFS and set the IdM DNS
domain.

7. Create an export to house the roaming home directories for IdM users.

8. Configure /etc/exports to share out the export utilizing Kerberos security. The krb5 mode
uses Kerberos version 5 protocol to authenticate users before granting access. The krb5i
mode adds data integrity checking. The krb5p mode further adds data encryption.

9. Enable and start the nfs, nfs-server, and nfs-secure services.

RH362-RHEL-7.4-en-1-20181003 333
CHAPTER 8 | Integrating Red Hat Products With IdM

CONFIGURING NFS CLIENT

The following steps outline the process for configuring an IdM client as a Kerberos-aware NFS
client for roaming IdM user home directories.

1. Execute the ipa-client-automount command to enable secure NFS and set the IdM DNS
domain.

2. Enable and start the rpc-gssd, rpcbind, and nfs-idmapd services.

CONFIGURING IDM AUTOMOUNT

The following steps outline the process for configuring automount in the IdM directory for the
implementation of roaming IdM user home directories.

1. In IdM, an automount location serves as a container for automount maps. One location already
exists because IdM automatically creates a default location. To house automount maps in
a new, separate container, create a new location using the ipa automountlocation-add
command.

[root@idmserver ~]# ipa automountlocation-add location

2. When a new location is created, two maps are automatically created within it. One map is
auto.master, which serves as the root map for all automount maps in the location. The other
map is auto.direct, which contains the default map for direct mounts.

Create a map to define resources for the roaming user home directory. Indirect maps are
created with the ipa automountmap-add-indirect command.

[root@idmserver ~]# ipa automountmap-add-indirect location auto.home --mount=/

home

3. Use the ipa automountkey-add command to add an indirect wildcard key for all roaming
user home directories to the newly created indirect map. The --key option defines the
mount point. The --info option defines the location of the NFS share containing the home
directories, along with the mount options to be used to mount the share.

[root@idmserver ~]# ipa automountkey-add location auto.home --key "*" --info

"nfsserver.lab.example.net:/export/home/&"

REFERENCES
Further information is available in the Using Automount section of the Red Hat
Enterprise Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
html/linux_domain_identity_authentication_and_policy_guide/index

334 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

GUIDED EXERCISE

CONFIGURING ROAMING HOME

DIRECTORIES
In this exercise, you will configure automounted roaming home directories for IdM users.

OUTCOMES
You should be able to

• Configure a Kerberos-aware NFS server and client.

• Create automount maps in IdM.

• Implement automounted roaming home directories for IdM users.

Log in to workstation as the student user and then open a terminal and execute the lab
products-roaming setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab products-roaming setup

1. Prepare the utility system for the implementation of a Kerberos-aware NFS server.
1.1. Login as the student user on utility, become root then obtain a Kerberos ticket
using the admin account and the RedHat123^ password.

[student@workstation ~]$ ssh utility

[student@utility ~]$ sudo -i
[sudo] password for student: student
[root@utility ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.2. Create a service principal for the NFS service on utility.lab.example.net.

[root@utility ~]# ipa service-add nfs/utility.lab.example.net

-----------------------------------------------------------
Added service "nfs/utility.lab.example.net@LAB.EXAMPLE.NET"
-----------------------------------------------------------
Principal name: nfs/utility.lab.example.net@LAB.EXAMPLE.NET
Principal alias: nfs/utility.lab.example.net@LAB.EXAMPLE.NET
Managed by: utility.lab.example.net

1.3. Generate, retrieve, and install the keytab for the new NFS service principal to /etc/
krb5.keytab.

[root@utility ~]# ipa-getkeytab -s idm.lab.example.net \

-p nfs/utility.lab.example.net -k /etc/krb5.keytab
Keytab successfully retrieved and stored in: /etc/krb5.keytab

RH362-RHEL-7.4-en-1-20181003 335
CHAPTER 8 | Integrating Red Hat Products With IdM

2. Set up the NFS server on utility and configure necessary firewall rules.
2.1. Verify that the nfs-utils package is installed.

[root@utility ~]# yum list nfs-utils

Loaded plugins: langpacks, search-disabled-repos
Installed Packages
nfs-utils.x86_64 1:1.3.0-0.48.el7 installed

2.2. Configure firewalld to allow access to the NFS service.

[root@utility ~]# firewall-cmd --add-service=nfs

success
[root@utility ~]# firewall-cmd --add-service=mountd
success
[root@utility ~]# firewall-cmd --add-service=rpc-bind
success
[root@utility ~]# firewall-cmd --add-service=nfs --permanent
success
[root@utility ~]# firewall-cmd --add-service=mountd --permanent
success
[root@utility ~]# firewall-cmd --add-service=rpc-bind --permanent
success

3. Configure both the NFS server and the IdM server to support older encryption options.
3.1. On utility, configure Kerberos to support older encryption options by adding the
following entry to the top of the /etc/krb5.conf configuration file.

allow_weak_crypto = true

3.2. As the root user on idm, configure Red Hat IdM to support older encryption
using the ldapmodify command. Use the Directory Manager account and its
password, RedHat123^, to make the modifications. After execution, the command
will wait for input so there will not be a prompt.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]# ldapmodify -x -D "cn=Directory Manager" -w RedHat123^ \
-h idm.lab.example.net -p 389 <<EOF
dn: cn=lab.example.net,cn=kerberos,dc=lab,dc=example,dc=net
changetype: modify
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:normal
-
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:special
-
add: krbDefaultEncSaltTypes
krbDefaultEncSaltTypes: des-cbc-crc:special
EOF

336 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

modifying entry "cn=lab.example.net,cn=kerberos,dc=lab,dc=example,dc=net"

3.3. Exit the terminal session on the idm system.

[root@idm ~]# exit

[student@idm ~]$ exit
[student@workstation ~]$

4. On utility, as the root user, use the ipa-client-automount command to enable

secure NFS and to set the IdM DNS domain.

[root@utility ~]# ipa-client-automount

Searching for IPA server...
IPA server: DNS discovery
Location: default
Continue to configure the system with these values? [no]: yes
Configured /etc/sysconfig/nfs
Configured /etc/idmapd.conf
Started rpcidmapd
Started rpcgssd
Restarting sssd, waiting for it to become available.
Started autofs

5. On utility, configure a Kerberos-aware NFS export of the /export/home directory to be

used for roaming home directories.
5.1. Create the /export/home directory.

[root@utility ~]# mkdir -p /export/home

5.2. Add the following entry to the /etc/exports file.

/export/home *(rw,sec=krb5:krb5i:krb5p)

5.3. Execute the exportfs command to export the new share.

[root@utility ~]# exportfs -ra

6. On utility, enable and start the NFS server and related services.
6.1. Enable the NFS server and related services.

[root@utility ~]# systemctl enable nfs

Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-
server.service to /usr/lib/systemd/system/nfs-server.service.
[root@utility ~]# systemctl enable nfs-server
[root@utility ~]# systemctl enable nfs-secure

6.2. Start the NFS server and related services.

[root@utility ~]# systemctl start nfs

[root@utility ~]# systemctl start nfs-server

RH362-RHEL-7.4-en-1-20181003 337
CHAPTER 8 | Integrating Red Hat Products With IdM

[root@utility ~]# systemctl start nfs-secure

7. On utility, configure the automount map and key.

7.1. Create the auto.home automount map in the default location.

[root@utility ~]# ipa automountmap-add-indirect default auto.home --mount=/home

-------------------------------
Added automount map "auto.home"
-------------------------------
Map: auto.home

7.2. Start the NFS server and related services.

[root@utility ~]# ipa automountkey-add default auto.home --key "*" \

--info "utility.lab.example.net:/export/home/&"
-----------------------
Added automount key "*"
-----------------------
Key: *
Mount information: utility.lab.example.net:/export/home/&

8. Configure client as a Kerberos-aware NFS client.

8.1. On client, execute the ipa-client-automount command to configure its NFS
settings for Kerberos-aware NFS.

[root@client ~]# ipa-client-automount

8.2. Enable and start the rpc-gssd, rpcbind, and nfs-idmapd services.

[root@client ~]# systemctl enable rpc-gssd

[root@client ~]# systemctl enable rpcbind
[root@client ~]# systemctl enable nfs-idmapd
[root@client ~]# systemctl start rpc-gssd
[root@client ~]# systemctl start rpcbind
[root@client ~]# systemctl start nfs-idmapd

8.3. Exit the terminal session on client.

[root@client ~]# exit

338 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

9. Create a roaming home directory for the productsuser01 user.

9.1. On utility, as the root user, create the /export/home/productsuser01
directory.

[root@utility ~]# mkdir /export/home/productsuser01

9.2. Create a README.txt, with the content "Roam", in the /export/home/

productsuser01 directory.

[root@utility ~]# echo "Roam" > /export/home/productsuser01/README.txt

9.3. Configure ownership and permissions on the /export/home/productsuser01

directory.

[root@utility ~]# chown -R productsuser01:productsuser01 \

/export/home/productsuser01
[root@utility ~]# chmod 700 /export/home/productsuser01

10. Verify that the roaming home directory for the productsuser01 user is accessible on
another IdM client system. Log in to the client system as the productsuser01 user with
the password redhat. Upon first login, you are prompted to change the password. Change
the password to redhatnew.
10.1. From workstation, use ssh to log in to the client system as the
productsuser01 user without using public key authentication.

[student@workstation ~]$ ssh -o PubkeyAuthentication=no \

productsuser01@client.lab.example.net
Password: redhat

10.2. Verify that the README.txt created earlier is present in the home directory.

-sh-4.2$ ls -la
total 8
drwx------. 4 productsuser01@lab.example.net productsuser01@lab.example.net 74 Apr
5 10:10 .
drwxr-xr-x. 3 root root 0 Apr
5 10:09 ..
-rw-------. 1 productsuser01@lab.example.net productsuser01@lab.example.net 9 Apr
5 10:10 .bash_history
drwxrwxr-x. 3 productsuser01@lab.example.net productsuser01@lab.example.net 18 Apr
5 10:09 .cache
drwxrwxr-x. 3 productsuser01@lab.example.net productsuser01@lab.example.net 18 Apr
5 10:09 .config
-rw-r--r--. 1 productsuser01@lab.example.net productsuser01@lab.example.net 16 Apr
5 10:10 README.txt
-sh-4.2$ cat README.txt
Roam

Cleanup
From workstation, run the lab products-roaming cleanup command to clean up this
exercise.

RH362-RHEL-7.4-en-1-20181003 339
CHAPTER 8 | Integrating Red Hat Products With IdM

[student@workstation ~]$ lab products-roaming cleanup

This concludes the guided exercise.

340 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

INTEGRATING SATELLITE 6 WITH IDM

OBJECTIVES
After completing this section, students should be able to:

• Configure IdM as the LDAP back end for Satellite Server.

• Create a deployment plan using IdM domains.

• Provision an IdM client using Satellite Server.

ENTERPRISE MANAGEMENT WITH SATELLITE SERVER

Red Hat Satellite 6 is a systems management tool that can be used to configure new systems
and provide software updates from Red Hat Network. It serves as a local repository of software
content and a central point of management for Red Hat entitlements. Red Hat Satellite also
performs provisioning and configuration management of systems to adhere to predefined standard
operating environments.

With the addition of the Satellite capsule server to its architecture, Red Hat Satellite 6 can scale
effectively to meet the demands of large enterprises. With the correct design, Satellite Server,
in conjunction with Satellite capsule servers, delivers solid performance in the face of increasing
workloads, even across a geographically distributed environment.

Several options are available for administering Satellite Server. A web browser can be used
to manage Satellite Server through its web UI. A command-line interface is also available for
administration of Satellite Server. For administrators with programming experience who desire
custom workflows or task automation, an API is available for interacting with Satellite Server.

Access to Satellite's various administration interfaces requires user authentication. Satellite Server
uses Role-Based Access Control (RBAC). Therefore, each user account's assigned role determines
the extent of their administrative capacity.

CONFIGURING EXTERNAL AUTHENTICATION WITH

IDM
By default, Satellite Server maintains a local, internal database of user accounts, which it uses for
local authentication of users. However, Satellite Server also supports various methods of external
authentication. Supported external authentication sources include LDAP, Active Directory, and IdM.

The following steps outline the process for configuring an existing Satellite Server installation for
external authentication using IdM.

1. Install the ipa-client and foreman-proxy packages on the Satellite Server system if they are not
already installed.

2. Configure the Satellite Server system to use the IdM server for DNS resolution.

3. Configure the Satellite Server system as an IdM client by running the ipa-client-install
command on the Satellite Server system.

4. On the IdM server, create a service principal for the HTTP service on the Satellite Server
system.

RH362-RHEL-7.4-en-1-20181003 341
CHAPTER 8 | Integrating Red Hat Products With IdM

5. Execute the satellite-installer command on the Satellite Server system with the
--foreman-ipa-authentication=true option to configure Satellite Server for IdM
authentication.

6. Restart the Katello service on the Satellite Server system with the katello-service
restart command.

When the configuration of Satellite Server for external authentication with IdM is complete, IdM
users can log in to the Satellite Server using their IdM credentials. If Kerberos single sign on is
configured in IdM, users can also obtain a ticket on their client machine and then log in to the
Satellite Server automatically. If IdM user are configured for two-factor authentication with one-
time password, they can also authenticate to the Satellite Server with a one-time password.

MANAGING SATELLITE SERVER ACCESS WITH HBAC

Once Satellite Server can perform external authentication with IdM, all IdM users gain access to
Satellite Server. To restrict Satellite Server access to a subset of the IdM user population, use IdM's
host-based access control (HBAC). HBAC rules dictate which systems within an IdM domain should
be accessible to an IdM user. Therefore, HBAC rules can restrict access to the Satellite Server to
only a subset of IdM users.

The following steps outline the process for configuring HBAC to restrict IdM user access to Satellite
Server.

1. Create an HBAC service and rule on the IdM server and link them together.

2. Add the Satellite Server system and the allowed IdM users or groups to the rule.

3. Ensure that the allow_all rule is disabled on the IdM server.

4. On the Satellite Server system, as the root user, define the PAM service using the
satellite-installer command in conjunction with the --foreman-pam-service
option. The following example defines a PAM service called sat_prod:

[root@satserver ~]# satellite-installer --foreman-pam-service=sat_prod

EXTERNAL AUTHENTICATION FOR PROVISIONED

HOSTS
While Satellite Server can utilize IdM as an external authentication source, hosts provisioned by
Satellite Server can also leverage IdM authentication. Using Satellite Server, you can provision
systems already configured for external authentication with IdM. Satellite Server's realm feature
makes this integration possible.

Satellite Server's realm feature is not enabled by default. You must enable this feature on Satellite
Server before you can create any realm resources within Satellite.

The following steps outline the process for configuring Satellite Server for IdM realm support.

1. Execute the foreman-prepare-realm command on the Satellite Server system to

configure the IdM server for integration with the Satellite Server. This command requires two
arguments. The first argument is the name of the IdM admin user. The second argument is
the name of the realm proxy user to create. The following example uses the IdM admin user
account to authenticate to the IdM server to create a realm proxy user account named realm-
capsule.

[root@satserver ~]# foreman-prepare-realm admin realm-capsule

342 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

Upon execution, the command creates a role on the IdM server with the permissions
needed by the Satellite Server for integration. The realm-capsule IdM user is created
with the new role. Additionally, the keytab file is retrieved from the IdM server to /root/
freeipa.keytab on the Satellite Server system.

2. On the Satellite Server system, move the installed /root/freeipa.keytab file to the /
etc/foreman-proxy directory. Set ownership of the file to the foreman-proxy user and
the foreman-proxy group.

3. Execute the satellite-installer command on the Satellite Server system to configure

Satellite Server for the provisioning of hosts configured to use IdM for external authentication.
Use the --foreman-proxy-realm true option to enable realm support. Use the --
foreman-proxy-realm-keytab /etc/foreman-proxy/freeipa.keytab option to
specify the file containing the keytab previously retrieved from the IdM server. Use the --
foreman-proxy-realm-principal 'realm-capsule@LAB.EXAMPLE.NET' option to
specify realm-capsule@LAB.EXAMPLE.NET as the principal to use for the integration with
IdM. Use the --foreman-proxy-realm-provider freeipa to specify freeipa as realm
provider.

[root@satserver ~]# satellite-installer \

--foreman-proxy-realm true
--foreman-proxy-realm-keytab /etc/foreman-proxy/freeipa.keytab \
--foreman-proxy-realm-principal 'realm-capsule@LAB.EXAMPLE.NET' \
--foreman-proxy-realm-provider freeipa

4. Install the IdM server's CA certificate to /etc/pki/ca-trust/source/anchors/ipa.crt

on the Satellite Server system.

5. Execute the update-ca-trust command to trust the IdM server's CA certificate.

6. Fix the value of the principal parameter in the /etc/foreman-proxy/settings.d/

realm_freeipa.yml file on the Satellite Server system. Ensure that the parameter is
configured with the same principal name as the one used for the Satellite Server's integration
with IdM.

7. Restart the foreman-proxy service.

8. Create the realm resource in the Satellite Server web user interface.

9. Associate the new realm resource with a host group resource used for host provisioning.

Enrolling Hosts into IdM Host Groups

In Satellite Server, host groups provide a means of grouping hosts into logical units. Hosts placed
in a host group inherit its configurations for software, network, operating system, and subscription
profiles.

Likewise, IdM also makes use of host group to group systems into logical units. When integrating
hosts provisioned by Satellite Server into an organization's IdM realm, it is desirable to be able to
enroll the host into the proper IdM host group based on its Satellite host group membership.

Automation of these host enrollments is possible by creating automembership rules within IdM. IdM
administrators can create automembership rules that enroll provisioned hosts into IdM host groups
based on the hosts' Satellite attributes.

For example, the userclass attribute identifies the Satellite host group that a host belongs to.
Therefore, to enroll provisioned hosts into IdM host groups based on their Satellite host group
membership, create an automembership rule that performs enrollments based on the value of the
userclass attribute.

RH362-RHEL-7.4-en-1-20181003 343
CHAPTER 8 | Integrating Red Hat Products With IdM

The following steps outline the process for automating IdM host group enrollment of Satellite-
provisioned hosts using automembership rules. These steps illustrate, for example, the rule and
condition for the enrollment of provisioned hosts in a Prod Satellite host group into an IdM
prod_servers host group.

1. Create the prod_servers host group in IdM.

[root@satserver ~]# ipa hostgroup-add prod_servers

2. In IdM, create an automembership rule using the ipa automember-add command. Use the
--type=hostgroup option to specify that the rule is for host group enrollment. Specify a
name, add_prod_servers, for the identification of the new automembership rule.

[root@satserver ~]# ipa automember-add --type=hostgroup add_prod_servers

3. In IdM, create a condition to act as a trigger for the new automembership rule using the ipa
automember-add condition command. This condition defines the criteria for triggering
the rule and the action to be taken.

Use the --type=hostgroup prod_servers option to specify that the condition triggers
enrollment into the prod_servers IdM host group. Use the --key=userclass option
to specify that the condition evaluates the value of the host's userclass attribute, which
contains its Satellite host group name. Use the --inclusive-regex='^Prod$' to define
the regular expression to use when evaluating the userclass attribute, including only
Satellite-provisioned hosts belonging to the Satellite Prod host group.

[root@satserver ~]# ipa automember-add-condition --type=hostgroup prod_servers --

key=userclass --inclusive-regex='^Prod$'

Provisioning Hosts for IdM Integration

With realm configuration and automembership rules in place, Satellite Server automatically
integrates systems into an organization's IdM realm during their provisioning. During host
provisioning, the integration of Satellite Server and IdM causes the following actions to
automatically take place.

• Satellite Server configures the new host as an IdM client.

• The IdM server creates a host principal for the host.

• The IdM server creates DNS records for the new host.

• The IdM server enrolls the new host into the appropriate IdM host group based on the host's
Satellite host group membership.

Once the provisioning of the new host completes, it is reachable on the network by DNS resolution.
It is also a member of the IdM realm, so it is able to authenticate using the IdM server without any
further manual configuration. Due to its automatic enrollment into an IdM host group, it is available
for management using IdM features, such as Host-Based Access Controls and sudo policies.

REFERENCES
Further information is available in the Configuring External Authentication section of
the Administering Red Hat Satellite Guide at
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.3/html/
administering_red_hat_satellite/

344 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

GUIDED EXERCISE

INTEGRATING SATELLITE 6 WITH IDM

In this exercise, you will configure Satellite Server for IdM authentication.

OUTCOMES
You should be able to configure Satellite Server for integration with Red Hat IdM.

• Configure IdM as the LDAP back end for Satellite Server.

Log in to workstation as the student user and then open a terminal and execute the lab
products-satellite setup command. This ensures that the classroom is ready for this
exercise.

[student@workstation ~]$ lab products-satellite setup

1. Prepare the Satellite Server to be a client of the LAB.EXAMPLE.NET IdM realm.

1.1. Open a terminal session and log in to satellite as the root user.

[student@workstation ~]$ ssh satellite

[student@satellite ~]$ sudo -i
[sudo] password for student: student
[root@satellite ~]#

1.2. Configure satellite to use the idm server for DNS resolution.

[root@satellite ~]# nmcli conn mod "System eth0" ipv4.dns "172.25.250.8"

[root@satellite ~]# systemctl restart network

2. Configure Satellite Server as a client of the LAB.EXAMPLE.NET IdM realm.

2.1. On satellite, install the ipa-client package.

[root@satellite ~]# yum install ipa-client

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

2.2. Use ipa-client-install to configure satellite as an IdM client and

enroll it to the IdM server. When prompted, use the admin Kerberos user and the
RedHat123^ password to gain authorization for the enrollment.

[root@satellite ~]# ipa-client-install

WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

RH362-RHEL-7.4-en-1-20181003 345
CHAPTER 8 | Integrating Red Hat Products With IdM

Discovery was successful!

Client hostname: satellite.lab.example.net
Realm: LAB.EXAMPLE.NET
DNS Domain: lab.example.net
IPA Server: idm.lab.example.net
BaseDN: dc=lab,dc=example,dc=net

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

Skipping synchronizing time with NTP server.
User authorized to enroll computers: admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Valid From: 2018-04-11 05:15:55
Valid Until: 2038-04-11 05:15:55

Enrolled in IPA realm LAB.EXAMPLE.NET

Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm LAB.EXAMPLE.NET
trying https://idm.lab.example.net/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://idm.lab.example.net/ipa/json'
trying https://idm.lab.example.net/ipa/session/json
[try 1]: Forwarding 'ping' to json server 'https://idm.lab.example.net/ipa/
session/json'
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://idm.lab.example.net/
ipa/session/json'
Systemwide CA database updated.
Hostname (satellite.lab.example.net) does not have A/AAAA record.
Missing reverse record(s) for address(es): 172.25.250.7.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
[try 1]: Forwarding 'host_mod' to json server 'https://idm.lab.example.net/ipa/
session/json'
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring lab.example.net as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

3. Prepare the IdM realm for the integration of the satellite server.
3.1. On satellite, use the kinit command to authenticate as the admin Kerberos
user with the RedHat123^ password.

[root@satellite ~]# kinit admin

346 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3.2. Create a service principal for the HTTP service on satellite.

[root@satellite ~]# ipa service-add HTTP/satellite.lab.example.net

--------------------------------------------------------------
Added service "HTTP/satellite.lab.example.net@LAB.EXAMPLE.NET"
--------------------------------------------------------------
Principal name: HTTP/satellite.lab.example.net@LAB.EXAMPLE.NET
Principal alias: HTTP/satellite.lab.example.net@LAB.EXAMPLE.NET
Managed by: satellite.lab.example.net

4. Enable IdM authentication on satellite.

4.1. Configure the Satellite Server for IdM authentication.

[root@satellite ~]# satellite-installer --foreman-ipa-authentication=true

Installing Done [100%]
[...............................................]
Success!
* Satellite is running at https://satellite.lab.example.net

* To install an additional Capsule on separate machine continue by running:

capsule-certs-generate --foreman-proxy-fqdn "$CAPSULE" --certs-tar "/root/

$CAPSULE-certs.tar"

* To upgrade an existing 6.2 Capsule to 6.3:

Please see official documentation for steps and parameters to use when
upgrading a 6.2 Capsule to 6.3.

The full log is at /var/log/foreman-installer/satellite.log

4.2. Restart Katello on satellite with the katello-service command. This makes
the changes to the IdM authentication configuration take effect.

[root@satellite ~]# katello-service restart

/usr/sbin/service-wait foreman-tasks stop
Redirecting to /bin/systemctl stop foreman-tasks.service

...output omitted...

/usr/sbin/service-wait foreman-tasks start

Redirecting to /bin/systemctl start foreman-tasks.service

Success!

5. Verify IdM authentication by logging in to the web user interface on satellite.

5.1. From workstation, connect to https://satellite.lab.example.net using
the Firefox web browser.
5.2. You will receive a warning because the Satellite Server is using a self-signed
certificate. Click Advanced, Add Exception, Confirm Security Exception.
5.3. Authenticate into the Satellite web user interface using the Kerberos admin user
name and the RedHat123^ password.

RH362-RHEL-7.4-en-1-20181003 347
CHAPTER 8 | Integrating Red Hat Products With IdM

Cleanup
From workstation, run the lab products-satellite cleanup command to clean up this
exercise.

[student@workstation ~]$ lab products-satellite cleanup

This concludes the guided exercise.

348 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

INTEGRATING ANSIBLE TOWER WITH IDM

OBJECTIVES
After completing this section, students should be able to:

• Configure IdM as the LDAP back end for Ansible Tower.

• Create teams, users, roles.

• Create a dynamic inventory of IdM hosts.

ENTERPRISE SYSTEM MANAGEMENT WITH ANSIBLE

TOWER
Ansible is an open source automation platform that can manage powerful automation tasks,
and can adapt to many different workflows and environments. As your experience with Ansible
matures, you will likely find additional opportunities for leveraging Ansible to simplify and improve
IT operations.

However, sharing an existing Ansible infrastructure to scale IT automation across an enterprise can
present some challenges. For instance, Ansible does not provide any facilities for managing shared
access of Ansible playbooks. Additionally, though playbooks may allow for delegation of complex
tasks, their execution may require highly privileged and guarded administrator credentials.

Ansible Tower overcomes many of these challenges by providing a framework for running and
managing Ansible efficiently on an enterprise scale. Tower eases the administration involved with
sharing an Ansible infrastructure while maintaining an organization's security by introducing
features such as a centralized web interface for playbook management, role-based access control
(RBAC), and centralized logging and auditing.

CONFIGURING LDAP AUTHENTICATION WITH IDM

By default, Ansible Tower maintains a local, internal database of user accounts, which it uses for
local authentication of users. However, Ansible Tower supports other methods of authentication.
Supported authentication methods include Microsoft Azure Active Directory, SAML, Radius, and
LDAP.

Organizations with both Red Hat IdM and Ansible Tower infrastructure can configure Ansible Tower
for authentication using IdM. To authenticate using IdM, you must configure Ansible Tower for
LDAP authentication. This configuration requires the use of a bind account, which has read access
to the entire LDAP structure on the Red Hat IdM server.

The following example shows how to use the ldapmodify command to create a bind account,
uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net, to be used by
Ansible Tower for LDAP authentication against IdM. The new account uses an initial password of
tower123.

[root@idmserver ~]# ldapmodify -x -D 'cn=Directory Manager' -W <<EOF

dn: uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system

RH362-RHEL-7.4-en-1-20181003 349
CHAPTER 8 | Integrating Red Hat Products With IdM

userPassword: tower123
passwordExpirationTime: 20280101000000Z
nsIdleTimeout: 0
EOF

Account creation requires elevated privileges. In the example, the -x option specifies the use of
simple authentication. The -D 'cn=Directory Manager' option configures ldapmodify to
perform its action using the privileged Directory Manager distinguished name. Finally, the -W
option prompts for the password of the Directory Manager distinguished name.

Querying LDAP Authentication

In order to configure Ansible Tower for LDAP authentication with Red Hat IdM, you need both a
bind account to access the LDAP directory, and you must have knowledge of the structure of the
LDAP directory. Using a bind account with access to read the entire LDAP directory on the Red
Hat IdM server, you can determine the structure of the LDAP directory by querying it with the
ldapsearch command.

The following command demonstrates the use of the ldapsearch command to execute a query
for the ipausers user group.

[root@idmserver ~]# ldapsearch \

-D "uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net" \
-W -h idm.lab.example.net \
-b "cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net"

In the preceding example, the -D option specifies

uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net as
the bind DN. The -W option prompts for the bind password. The -h option specifies
idm.lab.example.net as the target for the query. The -b option specifies
cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net as the base DN for
the search.

Conﬁguring Ansible Tower LDAP Authentication

The following steps outline the process for configuring Ansible Tower to authenticate using IdM's
LDAP directory.

1. Log in to Ansible Tower with an administrator account.

2. Click the Settings icon and then CONFIGURE TOWER.

3. On the CONFIGURE TOWER page, click on AUTHENTICATION and then select LDAP from the
SUB CATEGORY drop-down list.

4. Enter the LDAP URI for the IdM server in the LDAP SERVER URI field.

5. In the LDAP BIND DN field, enter the DN for the new bind account, which has access to read
the entire LDAP structure on the IdM server.

6. In the LDAP BIND PASSWORD field, enter the password for the bind account displayed in the
LDAP BIND DN field.

7. In the LDAP USER SEARCH field, define the base DN, the search scope, and the search query
format for user searches during authentication. The following example demonstrates the user
search parameters for querying by user UID in the lab.example.net domain using the
subtree scope.

CN=users,CN=accounts,DC=lab,DC=example,DC=net

350 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

SCOPE_SUBTREE
(uid=%(user)s)

8. Click SAVE to commit the change.

MAPPING USER ATTRIBUTES

The first time an IdM user authenticates and logs into Ansible Tower, Tower creates a user account
for the user in its local user database. Tower creates the new user account with a name matching
that of the IdM user account. Other than the account name, Tower does not bring any other user
account information over from IdM. To obtain user information such as first and last names and
populate them into the Tower user database, create a LDAP user attribute map in Tower's LDAP
authentication configuration.

The following steps outline the process for configuring Ansible Tower to map IdM user attributes to
Tower user account data elements.

1. Log in to Ansible Tower with an administrator account.

2. Click the Settings icon and then CONFIGURE TOWER.

3. On the CONFIGURE TOWER page, click on AUTHENTICATION, and then select LDAP from the
SUB CATEGORY drop-down list.

4. In the LDAP USER ATTRIBUTE MAP field, enter the desired mapping in JSON format. The
following example demonstrates the mapping of the first_name, last_name, and email
user attributes.

{
"first_name": "givenName",
"last_name": "sn",
"email": "mail"
}

5. Click SAVE to commit the change.

ENABLING USER FLAGS BY GROUP

Tower allows groups of users to be mapped to specific user flags in Tower. Once the mapping
configuration is in place, any IdM user belonging to the specified group is added to Tower with the
specified flag enabled.

The following steps outline the process for configuring Ansible Tower to map an IdM user group to
a Tower user flag.

1. Log in to Ansible Tower with an administrator account.

2. Click the Settings icon and then CONFIGURE TOWER.

3. On the CONFIGURE TOWER page, click AUTHENTICATION and then select LDAP from the
SUB CATEGORY drop-down list.

4. In the LDAP USER FLAGS BY GROUP field, enter the desired mapping in JSON format. The
following example demonstrates the mapping of users in the toweradmin IdM user group to
the is_superuser flag in Tower.

{
"is_superuser": "CN=toweradmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=net"
}

RH362-RHEL-7.4-en-1-20181003 351
CHAPTER 8 | Integrating Red Hat Products With IdM

5. Click SAVE to commit the change.

MANAGING TOWER ACCESS BY IDM USER GROUP

Once Ansible Tower can perform external authentication using IdM's LDAP directory, all IdM users
gain access to Ansible Tower. The Tower administrator can manage IdM user access to Ansible
Tower based on their group memberships in IdM.

Group-based access to Tower can be managed using inclusion, exclusion, or a combination of both
methods. The following steps outline the process for configuring Ansible Tower to map IdM user
attributes to Tower user account data elements.

1. Log in to Ansible Tower with an administrator account.

2. Click the Settings icon and then CONFIGURE TOWER.

3. On the CONFIGURE TOWER page, click on AUTHENTICATION and then select LDAP from the
SUB CATEGORY drop-down list.

4. Select GroupofNamesType in the LDAP GROUP TYPE field.

5. To allow user access by group membership, in the LDAP REQUIRE GROUP field, enter the
DN for the group to allow. The following example allows Tower access for IdM users in the
prodadmin IdM user group in the lab.example.net domain:

CN=prodadmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=net

6. To restrict user access by group membership, enter the DN for the group to deny in the LDAP
DENY GROUP field. The following example denies Tower access for IdM users in the produser
IdM user group in the lab.example.net domain:

CN=produser,CN=groups,CN=accounts,DC=lab,DC=example,DC=net

7. Click SAVE to commit the change.

MAPPING IDM USERS TO ORGANIZATIONS AND

TEAMS
In Ansible Tower, an organization is a logical unit containing a set of related Tower resources, such
as teams, projects, and inventories. By associating users with an organization, an administrator can
then manage their level of access to the resources contained within the organization.

In Ansible Tower, a team is a group of users. Ansible Tower utilizes role-based access control and
teams are an efficient way to manage roles. Teams allow role assignment to be made on a group of
users rather than independently on each individual user.

When importing users into Ansible Tower from IdM, it is useful to be able to automatically place
users into the organization containing resources they need. Ansible Tower's LDAP authentication
configuration allows this automation through the mapping of users to organization based on
their IdM user group membership. Besides user-to-organization mapping, Ansible Tower's LDAP
authentication configuration can also automate the mapping of users to teams based on their IdM
user group membership.

The following steps outline the process for configuring the mapping of IdM users to Ansible Tower
organizations and teams.

1. Log in to Ansible Tower with an administrator account.

352 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

2. Click the Settings icon and then CONFIGURE TOWER.

3. On the CONFIGURE TOWER page, click on AUTHENTICATION and then select LDAP from the
SUB CATEGORY drop-down list.

4. In the LDAP GROUP SEARCH field, define the base DN, the search scope, and the search
query format for searching user groups in IdM. The following example demonstrates
the group search parameters when querying for the ipausergroup objectClass in the
lab.example.net domain using the subtree scope.

CN=groups,CN=accounts,DC=lab,DC=example,DC=net
SCOPE_SUBTREE
(objectClass=ipausergroup)

5. To map IdM users to Tower organizations, specify the mapping in JSON format in the LDAP
ORGANIZATION MAP field. The following example maps IdM users in the labadmin IdM user
group in the lab.example.net domain to the Lab organization as administrators.

{
"Lab": {
"admins": "CN=labadmin,CN=groups,CN=accounts,DC=lab,DC=example,DC=net"
}
}

6. To map IdM users to a Tower organization and team, specify the mapping in JSON format in
the LDAP TEAM MAP field. The following example maps Tower access for IdM users in the
produsers IdM user group in the lab.example.net domain to the Prod organization as
users and members of the produsers team. The "remove": false entry prevents users
who are not members of the group from being removed from the team.

{
"produsers": {
"organization": "Prod",
"users": "CN=produsers,CN=groups,CN=accounts,DC=lab,DC=example,DC=net",
"remove": false
}
}

7. Click SAVE to commit the change.

CREATING DYNAMIC INVENTORIES

When Ansible runs a playbook, it uses an inventory to help determine which hosts the plays should
be run against. Both Ansible and Ansible Tower make it easy to set up a static inventory of hosts
explicitly specified in the inventory by the administrator.

However, these static lists require manual administration in order to keep them updated. This
can be inconvenient or challenging, especially when an organization wants to run the playbooks
against hosts that are dynamically created in a virtualization or cloud computing environment.

In that scenario, it is useful to use a dynamic inventory. Dynamic inventories are scripts that,
when run, dynamically determine which hosts and host groups should be in the inventory
based on information from some external source. These can include the API for cloud providers,
Cobbler, LDAP directories, or other third party CMDB software. Using a dynamic inventory is
a recommended practice in a large and quickly changing IT environment, where systems are
frequently deployed, tested, and then removed.

RH362-RHEL-7.4-en-1-20181003 353
CHAPTER 8 | Integrating Red Hat Products With IdM

By default, Ansible Tower comes with built-in dynamic inventory support for a number of external
inventory sources (or cloud inventory sources), including:

• Amazon EC2

• Google Compute Engine

• Microsoft Azure Resource Manager

• VMware vCenter

• Red Hat Satellite 6

• Red Hat CloudForms

• OpenStack

In addition, it is possible to use custom dynamic inventory scripts in Ansible Tower to access
inventory information from other sources.

CUSTOM DYNAMIC INVENTORY SCRIPTS

Ansible allows you to write custom scripts to generate a dynamic inventory. While Ansible Tower
offers built-in support for a number of dynamic inventory sources, custom dynamic inventory
scripts can also be used with Ansible Tower.

Writing or Obtaining Custom Inventory Scripts

Ansible Tower supports custom inventory scripts written in any dynamic language installed on the
Ansible Tower server. By default, Ansible Tower supports Python and BASH, but more languages
can be added. These scripts run as the awx user and have limited access to the Tower server. The
script must start with an appropriate shebang line (for example, #!/usr/bin/python for a
Python script).

Many examples of custom inventory scripts for use with various external sources have been
contributed by the community to the Git repository for Ansible at https://github.com/ansible/
ansible/tree/devel/contrib/inventory/.

Using Custom Inventory Scripts in Ansible Tower

Once you have created or downloaded the appropriate custom inventory script, you need to import
it into Ansible Tower and configure the Inventory. Below is a demonstration:

To upload a custom inventory script into Tower, go to Settings. From the available options, choose
INVENTORY SCRIPTS.

354 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

Figure 8.1: Ansible Tower Settings

You can now add a new custom inventory script by clicking the ADD button.

Define a new name for the custom inventory script in the NAME field, and copy and paste the
actual script in to the CUSTOM SCRIPT text box. Click the SAVE button.

Figure 8.2: Adding new custom inventory script

Once the dynamic inventory script has been installed in Ansible Tower, you configure it just like any
of the built-in dynamic inventories:

1. Create a new Group in an Inventory for the dynamic inventory. Set its SOURCE to Custom
Script and CUSTOM INVENTORY SCRIPT to the name you set for the custom script that you
just imported into Ansible Tower.

2. Synchronize the Group with the inventory source, as discussed for the OpenStack and Red Hat
Satellite 6 dynamic inventory sources.

RH362-RHEL-7.4-en-1-20181003 355
CHAPTER 8 | Integrating Red Hat Products With IdM

Figure 8.3: Adding new Inventory Group for custom dynamic inventory

REFERENCES
Ansible Tower Administration Guide
http://docs.ansible.com/ansible-tower/latest/html/administration

356 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

GUIDED EXERCISE

INTEGRATING ANSIBLE TOWER WITH IDM

In this exercise, you will configure Ansible Tower to use IdM as its authentication engine and
store.

OUTCOMES
You should be able to:

• Configure IdM as the LDAP back end for Ansible Tower.

• Manage IdM user access to Ansible Tower.

• Map IdM user attributes to Tower user properties.

Log in to workstation as the student user and then open a terminal and execute the lab
products-tower setup command. This ensures that the classroom is ready for this exercise.

[student@workstation ~]$ lab products-tower setup

1. On idm, create a bind user, tower, for use by Ansible Tower to query LDAP on the Red Hat
IdM server.
1.1. Open a terminal session to the idm system as the student user, then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

1.2. Using kinit, authenticate as the admin Kerberos user with the RedHat123^
password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.3. Using the ldapmodify command, authenticate as the Directory Manger

Kerberos user with the RedHat123^ password and create a user, tower, which has
access to read the entire LDAP structure on the Red Hat IdM server.

[root@idm ~]# ldapmodify -x -D 'cn=Directory Manager' -W <<EOF

dn: uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: tower123
passwordExpirationTime: 20280101000000Z
nsIdleTimeout: 0

RH362-RHEL-7.4-en-1-20181003 357
CHAPTER 8 | Integrating Red Hat Products With IdM

EOF

2. Use the newly created bind account to determine where the user accounts reside in the
LDAP tree structure on the Red Hat IdM server.
2.1. Execute the ldapsearch command to query LDAP starting at the base,
dc=lab,dc=example,dc=net. Make the query using the new bind user account
and its password to verify that the account is working properly. Query for the
productsuser02 user account.

[root@idm ~]# ldapsearch \

-D "uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net" \
-W -h idm.lab.example.net \
-b "cn=accounts,dc=lab,dc=example,dc=net" \
uid=productsuser02
Enter LDAP Password: tower123
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=lab,dc=example,dc=net> with scope subtree
# filter: uid=productsuser02
# requesting: ALL
#

# productsuser02, users, accounts, lab.example.net

dn: uid=productsuser02,cn=users,cn=accounts,dc=lab,dc=example,dc=net
displayName: Products User02
uid: productsuser02
krbCanonicalName: productsuser02@LAB.EXAMPLE.NET
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
objectClass: ipantuserattrs
loginShell: /bin/sh
initials: PU
gecos: Products User02
sn: User02
homeDirectory: /home/productsuser02
mail: productsuser02@lab.example.net
krbPrincipalName: productsuser02@LAB.EXAMPLE.NET
givenName: Products
cn: Products User02
ipaUniqueID: 816eccf0-42bc-11e8-bd4a-52540000fa08
uidNumber: 1730200014
gidNumber: 1730200014
krbPasswordExpiration: 20990606060606Z
krbLastPwdChange: 20180418035641Z

358 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

memberOf: cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
memberOf: cn=productsgroup02,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
ipaNTSecurityIdentifier: S-1-5-21-210677182-3690456737-948912114-1014

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

2.2. In the output of ldapsearch, the user account information resides under the
cn=users,cn=accounts,dc=lab,dc=example,dc=net node of the tree.

dn: uid=productsuser02,cn=users,cn=accounts,dc=lab,dc=example,dc=net

2.3. Note that in the output of ldapsearch, the user group information resides under
the cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
node of the tree.

memberOf: cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net

3. Use the newly created bind account to determine which object class can be used to search
for user groups in the LDAP tree structure on the Red Hat IdM server.
3.1. Execute the ldapsearch command to query LDAP starting at the base,
cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net.
Make the query using the newly created bind user account and its password to verify
that the account is working properly.

[root@idm ~]# ldapsearch \

-D "uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net" \
-W -h idm.lab.example.net \
-b "cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net"
Enter LDAP Password: tower123
# extended LDIF
#
# LDAPv3
# base <cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net> with scope
subtree
# filter: (objectclass=*)
# requesting: ALL
#

# ipausers, groups, accounts, lab.example.net

dn: cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
description: Default group for all users
cn: ipausers
ipaUniqueID: 7565b58a-4123-11e8-8174-52540000fa08
member: uid=idmuser01,cn=users,cn=accounts,dc=lab,dc=example,dc=net

RH362-RHEL-7.4-en-1-20181003 359
CHAPTER 8 | Integrating Red Hat Products With IdM

member: uid=idmuser02,cn=users,cn=accounts,dc=lab,dc=example,dc=net
member: uid=idmuser03,cn=users,cn=accounts,dc=lab,dc=example,dc=net
member: uid=idmuser04,cn=users,cn=accounts,dc=lab,dc=example,dc=net
member: uid=idmuser05,cn=users,cn=accounts,dc=lab,dc=example,dc=net
member: uid=productsuser02,cn=users,cn=accounts,dc=lab,dc=example,dc=net

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

3.2. Note that in the output of ldapsearch, the user group has an objectClass of
ipausergroup.

objectClass: ipausergroup

4. Use the new bind account to determine which attributes correspond to an IdM user's first
name, last name, and email address.
4.1. Execute the ldapsearch command to query LDAP starting at the base,
cn=accounts,dc=lab,dc=example,dc=net. Make the query using the new bind
user account and its password to verify that the account is working properly. Query
for the productsuser02 user account.

[root@idm ~]# ldapsearch \

# productsuser02, users, accounts, lab.example.net

360 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

objectClass: mepOriginEntry
objectClass: ipantuserattrs
loginShell: /bin/sh
initials: PU
gecos: Products User02
sn: User02
homeDirectory: /home/productsuser02
mail: productsuser02@lab.example.net
krbPrincipalName: productsuser02@LAB.EXAMPLE.NET
givenName: Products
cn: Products User02
ipaUniqueID: 816eccf0-42bc-11e8-bd4a-52540000fa08
uidNumber: 1730200014
gidNumber: 1730200014
krbPasswordExpiration: 20990606060606Z
krbLastPwdChange: 20180418035641Z
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
memberOf: cn=productsgroup02,cn=groups,cn=accounts,dc=lab,dc=example,dc=net
ipaNTSecurityIdentifier: S-1-5-21-210677182-3690456737-948912114-1014

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

4.2. Note that in the output of ldapsearch, the user's first name is stored as the
givenName attribute.

givenName: Products

4.3. Note that in the output of ldapsearch, the user's first name is stored as the sn
attribute.

sn: User02

4.4. Note that in the output of ldapsearch, the user's email address is stored as the
mail attribute.

mail: productsuser02@lab.example.net

5. Configure Ansible Tower for LDAP authentication against Red Hat IdM.
5.1. From workstation, use the Firefox web browser to connect to the Ansible Tower web
interface at http://tower.lab.example.net.
5.2. You will receive a warning because the Tower Server is using a self-signed certificate.
Click Advanced, Add Exception, Confirm Security Exception.
5.3. Log in with the admin account, using redhat as the password.
5.4. Click on the Settings icon and then Configure Tower. On the EDIT CONFIGURATION
screen, select LDAP from the SUB CATEGORY drop-down list.
5.5. Enter ldap://idm.lab.example.net:389 into the LDAP SERVER URI field.
Enter uid=tower,cn=sysaccounts,cn=etc,dc=lab,dc=example,dc=net
into the LDAP BIND DN field. Enter tower123 into the LDAP BIND PASSWORD field.

RH362-RHEL-7.4-en-1-20181003 361
CHAPTER 8 | Integrating Red Hat Products With IdM

6. Configure Ansible Tower for LDAP User Search and LDAP Group Search.
6.1. On the EDIT CONFIGURATION screen in the Ansible Tower web user interface,
locate the LDAP USER SEARCH field. In this field, enter the following to indicate the
location in the LDAP tree structure where user account information is kept and how
user account information should be queried.

CN=users,CN=accounts,DC=lab,DC=example,DC=net
SCOPE_SUBTREE
(uid=%(user)s)

6.2. On the EDIT CONFIGURATION screen in the Ansible Tower web user interface, locate
the LDAP GROUP SEARCH field. In this field, enter the following to indicate the
location in the LDAP tree structure where user account information is kept and how
user account information should be queried.

CN=groups,CN=accounts,DC=lab,DC=example,DC=net
SCOPE_SUBTREE
(objectClass=ipausergroup)

6.3. On the EDIT CONFIGURATION screen in the Ansible Tower web user interface, locate
the LDAP GROUP TYPE field. In this field, select GroupOfNamesType.

7. Configure access to the Tower web user interface so that IdM users in the
productsgroup04 group are denied. On the EDIT CONFIGURATION screen in the Ansible
Tower web user interface, locate the LDAP DENY GROUP field. In this field, enter the
following to deny access to users of the productsgroup04 IdM user group:

CN=productsgroup04,CN=groups,CN=accounts,DC=lab,DC=example,DC=net

8. Map the IdM user attributes, givenName, sn, and mail, to Tower's first_name,
last_name, and email data elements. On the EDIT CONFIGURATION screen in the
Ansible Tower web user interface, locate the LDAP USER ATTRIBUTE MAP field. In this field,
enter the following to create the user attributes mapping.

{
"first_name": "givenName",
"last_name": "sn",
"email": "mail"
}

9. Configure Tower so that IdM users in the productsgroup02 group are mapped to Tower's
superuser role. On the EDIT CONFIGURATION screen in the Ansible Tower web user
interface, locate the LDAP USER FLAGS BY GROUP field. In this field, enter the following:

{
"is_superuser":
"CN=productsgroup02,CN=groups,CN=accounts,DC=lab,DC=example,DC=net"
}

10. Click SAVE to save all the changes made to the LDAP configuration. Click the Log Out icon
to log out of the Tower web user interface.

362 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

11. Verify LDAP authentication to the Tower web interface and user attribute mapping for the
productsuser02 IdM user.
11.1. Log in to the Tower web interface as the productsuser02 IdM user with the
tower123 password.
11.2. Click the Settings icon, and then USERS to see a list of user accounts created in
Tower.
11.3. Click on the productsuser02 link.
11.4. On the DETAILS screen, verify that the FIRST NAME, LAST NAME, and EMAIL fields
have been populated with information from IdM as configured by the user attribute
mapping created earlier.
11.5. Click the Log Out icon to log out of the Tower web user interface.

12. Verify LDAP authentication to the Tower web interface and user attribute mapping for the
productsuser03 IdM user.
12.1. Log in to the Tower web interface as the productsuser03 IdM user with the
tower123 password.
12.2. Click the Settings icon, and then USERS to see a list of user accounts created in
Tower.
12.3. Click on the productsuser03 link.
12.4. On the DETAILS screen, verify that the FIRST NAME, LAST NAME, and EMAIL fields
have been populated with information from IdM as configured by the user attribute
mapping created earlier.
12.5. Click the Log Out icon to log out of the Tower web user interface.

13. Verify LDAP authentication to the Tower web interface for the productsuser04 IdM user.
13.1. Log in to the Tower web interface as the productsuser04 IdM user with the
tower123 password.
13.2. Due to the deny access configuration, Tower should not allow productsuser04
access to the web user interface.

14. Verify that the group user flag configuration enabled the superuser role for only members of
the productsgroup02 IdM user group.
14.1. Log in to the Tower web interface as the productsuser02 IdM user with the
tower123 password.
14.2. Click the Settings icon, and then USERS to see a list of user accounts created in
Tower.
14.3. Click on the productsuser02 link. Notice that the user type is set to System
Administrator.
14.4. Click the USERS link in the breadcrumb navigation at the top left of the screen. Click
on the productsuser03 link. Notice that the user type is set to Normal User.

Cleanup
From workstation, run the lab products-tower cleanup command to clean up this
exercise.

[student@workstation ~]$ lab products-tower cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 363
CHAPTER 8 | Integrating Red Hat Products With IdM

LAB

INTEGRATING RED HAT PRODUCTS WITH

IDM

PERFORMANCE CHECKLIST
In this lab, you will configure roaming home directories and integrate Ansible Tower with IdM
for user mapping and dynamic inventories.

OUTCOMES
You should be able to:

• Configure roaming home directories.

• Configure mapping of IdM users to Ansible Tower organization resources.

• Configure mapping of IdM users to Ansible Tower team resources.

• Configure the creation of an Ansible Tower dynamic inventory with IdM host and host
group data.

Log in to workstation as student using student as the password. Run the lab products-
review setup command to configure the environment.

[student@workstation ~]$ lab products-review setup

1. Create a new share located at /export/reviewhome on utility for roaming home

directories.
2. Create the roaming home directory for the productsuser01 user under the newly created
share directory, /export/reviewhome, on utility. Create a file named README.txt
in the roaming home directory for the productsuser01. Populate the file with the text
"Roaming home directory".
3. Modify the existing automount configuration in IdM so that roaming home directories use the
new NFS export on utility.
4. Configure replica2 as a Kerberos-aware NFS client
5. Verify that the productsuser01 user can access their roaming home directory on
replica2 using the redhat password. Verify that the productsuser01 user can read the
contents of the README.txt file. As the productsuser01 user, create a file in the roaming
home directory called test.txt containing the content, "test".
6. Modify the existing IdM configuration in the Ansible Tower instance on tower so that all users
of the IdM productsgroup05 user group are granted admin role in a Tower organization
called Lab.
7. Modify the existing IdM configuration in the Ansible Tower instance on tower so that all
users of the IdM productsgroup06 user group are created as members in a team called
productsgroup06, in a Tower organization called Example.
8. Verify the Lab LDAP organization map by logging into the Ansible Tower web user interface
as the productsuser05 user with the tower123 password.

364 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

9. Verify the productsuser06 LDAP team map by logging into the Ansible Tower web user
interface as the productuser06 user with the tower123 password.
10. Add the http://materials.example.com/labs/products-review/ldap-idm.py
inventory script to the Ansible Tower instance.
11. Create a dynamic inventory using the IdM Custom Inventory custom inventory script.

Evaluation
From workstation, run the lab products-review grade command to confirm the success
of this exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab products-review grade

Cleanup
From workstation, run the lab products-review cleanup command to clean up this lab.

[student@workstation ~]$ lab products-review cleanup

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 365
CHAPTER 8 | Integrating Red Hat Products With IdM

SOLUTION

INTEGRATING RED HAT PRODUCTS WITH

IDM

PERFORMANCE CHECKLIST
In this lab, you will configure roaming home directories and integrate Ansible Tower with IdM
for user mapping and dynamic inventories.

OUTCOMES
You should be able to:

• Configure roaming home directories.

• Configure mapping of IdM users to Ansible Tower organization resources.

• Configure mapping of IdM users to Ansible Tower team resources.

• Configure the creation of an Ansible Tower dynamic inventory with IdM host and host
group data.

Log in to workstation as student using student as the password. Run the lab products-
review setup command to configure the environment.

[student@workstation ~]$ lab products-review setup

1. Create a new share located at /export/reviewhome on utility for roaming home

directories.
1.1. Log in as the student user to utility, become root then obtain a Kerberos ticket
using the admin account and the RedHat123^ password.

[student@workstation ~]$ ssh utility

[student@utility ~]$ sudo -i
[sudo] password for student: student
[root@utility ~]# kinit admin
Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.2. Create the share directory.

[root@utility ~]# mkdir /export/reviewhome

1.3. Change the current NFS server configuration so that the existing export points to the
location of the new share. The /etc/exports configuration file contain the following
contents.

/export/reviewhome *(rw,sec=krb5:krb5i:krb5p)

1.4. Execute the exportfs command to export the new share.

366 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

[root@utility ~]# exportfs -ra

2. Create the roaming home directory for the productsuser01 user under the newly created
share directory, /export/reviewhome, on utility. Create a file named README.txt
in the roaming home directory for the productsuser01. Populate the file with the text
"Roaming home directory".
2.1. As the root on utility, create the roaming home directory for the
productsuser01 user.

[root@utility ~]# mkdir /export/reviewhome/productsuser01

2.2. Create the README.txt file in the roaming home directory for the productsuser01
user.

[root@utility ~]# echo "Roaming home directory" > \

/export/reviewhome/productsuser01/README.txt

2.3. Set the ownership and permission on the new roaming home directory and its
contents.

[root@utility ~]# chown -R productsuser01:productsuser01 \

/export/reviewhome/productsuser01
[root@utility ~]# chmod 700 /export/reviewhome/productsuser01

3. Modify the existing automount configuration in IdM so that roaming home directories use the
new NFS export on utility.
3.1. As the root user on utility, display the current IdM automount configuration.

[root@utility ~]# ipa automountlocation-tofiles

Location: default
/etc/auto.master:
/- /etc/auto.direct
/home /etc/auto.home
---------------------------
/etc/auto.direct:
---------------------------
/etc/auto.home:
* utility.lab.example.net:/export/home/&

maps not connected to /etc/auto.master:

3.2. Modify the IdM automount configuration to point to the location of the new NFS share
for roaming home directories.

[root@utility ~]# ipa automountkey-mod default auto.home \

--key "*" --info "utility.lab.example.net:/export/reviewhome/&"
--------------------------
Modified automount key "*"
--------------------------
Key: *

RH362-RHEL-7.4-en-1-20181003 367
CHAPTER 8 | Integrating Red Hat Products With IdM

Mount information: utility.lab.example.net:/export/reviewhome/&

3.3. Verify the new IdM automount configuration.

[root@utility ~]# ipa automountlocation-tofiles

maps not connected to /etc/auto.master:

4. Configure replica2 as a Kerberos-aware NFS client

4.1. As the root user on replica2, execute the ipa-client-automount command to
configure its NFS settings for Kerberos-aware NFS.

[student@workstation ~]$ ssh replica2

[student@replica2 ~]$ sudo -i
[sudo] password for student: student
[root@replica2 ~]# ipa-client-automount
Searching for IPA server...
IPA server: DNS discovery
Location: default
Continue to configure the system with these values? [no]: yes
Configured /etc/sysconfig/nfs
Configured /etc/idmapd.conf
Started rpcidmapd
Started rpcgssd
Restarting sssd, waiting for it to become available.
Started autofs

4.2. Enable and start the rpc-gssd, rpcbind, and nfs-idmapd services.

[root@replica2 ~]# systemctl enable rpc-gssd

[root@replica2 ~]# systemctl enable rpcbind
[root@replica2 ~]# systemctl enable nfs-idmapd
[root@replica2 ~]# systemctl start rpc-gssd
[root@replica2 ~]# systemctl start rpcbind
[root@replica2 ~]# systemctl start nfs-idmapd

4.3. Exit the terminal session on replica2.

[root@replica2 ~]# exit

5. Verify that the productsuser01 user can access their roaming home directory on
replica2 using the redhat password. Verify that the productsuser01 user can read the

368 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

contents of the README.txt file. As the productsuser01 user, create a file in the roaming
home directory called test.txt containing the content, "test".
5.1. From workstation, use SSH to log in to the replica2 system as the
productsuser01 user without using public key authentication.

[student@workstation ~]$ ssh -o PubkeyAuthentication=no \

productsuser01@replica2.lab.example.net
Password: redhat

5.2. List the contents of the roaming home directory to verify that README.txt is present
and readable by the productsuser01 user.

-sh-4.2$ ls -la
total 4
drwx------. 4 productsuser01@lab.example.net productsuser01@lab.example.net 53 Apr
18 13:09 .
drwxr-xr-x. 3 root root 0 Apr
18 13:09 ..
drwxrwxr-x. 3 productsuser01@lab.example.net productsuser01@lab.example.net 18 Apr
18 13:09 .cache
drwxrwxr-x. 3 productsuser01@lab.example.net productsuser01@lab.example.net 18 Apr
18 13:09 .config
-rw-r--r--. 1 productsuser01@lab.example.net productsuser01@lab.example.net 23 Apr
18 12:58 README.txt
-sh-4.2$ cat README.txt
Roaming home directory

5.3. Create the test.txt file in the roaming home directory for the productsuser01
user.

-sh-4.2$ echo "test" > test.txt

6. Modify the existing IdM configuration in the Ansible Tower instance on tower so that all users
of the IdM productsgroup05 user group are granted admin role in a Tower organization
called Lab.
6.1. From workstation, use the Firefox web browser to connect to the Ansible Tower web
interface at http://tower.lab.example.net.
6.2. Log in with the admin account and the redhat password.
6.3. Click on the Settings icon and then Configure Tower. On the EDIT CONFIGURATION
screen, select LDAP from the SUB CATEGORY drop-down list.
6.4. On the EDIT CONFIGURATION screen in the Ansible Tower web user interface, locate
the LDAP ORGANIZATION MAP field. In this field, enter the following organization
mapping.

{
"Lab": {
"admins": "CN=productsgroup05,CN=groups,CN=accounts,DC=lab,DC=example,DC=net"
}
}

6.5. Click SAVE.

RH362-RHEL-7.4-en-1-20181003 369
CHAPTER 8 | Integrating Red Hat Products With IdM

7. Modify the existing IdM configuration in the Ansible Tower instance on tower so that all
users of the IdM productsgroup06 user group are created as members in a team called
productsgroup06, in a Tower organization called Example.
7.1. In the Ansible Tower web user interface, click on the Settings icon and then click
Configure Tower. On the EDIT CONFIGURATION screen, select LDAP from the SUB
CATEGORY drop-down list.
7.2. On the EDIT CONFIGURATION screen in the Ansible Tower web user interface, locate
the LDAP TEAM MAP field. In this field, enter the following organization and team
mapping.

{
"productsgroup06": {
"organization": "Example",
"users": "CN=productsgroup06,CN=groups,CN=accounts,DC=lab,DC=example,DC=net",
"remove": false
}
}

7.3. Click SAVE.

7.4. Click the Log Out icon to log out of the Ansible Tower web interface.
8. Verify the Lab LDAP organization map by logging into the Ansible Tower web user interface
as the productsuser05 user with the tower123 password.
8.1. In the Ansible Tower web user interface, click the Settings icon, and then USERS to see
a list of user accounts created in Tower.
8.2. Click on the productsuser05 link.
8.3. Click on the PERMISSIONS tab. You should see that the productsuser05 user has
the Admin role granted to it for the Lab organization.
9. Verify the productsuser06 LDAP team map by logging into the Ansible Tower web user
interface as the productuser06 user with the tower123 password.
9.1. In the Ansible Tower web user interface, click the Settings icon, and then USERS to see
a list of user accounts created in Tower.
9.2. Click on the productsuser06 link.
9.3. Click on the PERMISSIONS tab. You should see that the productsuser06 user is a
member of the productsgroup06 team.
9.4. Click on the productsgroup06 link. You should see that the productsgroup06 team
belongs to the Example organization.
9.5. Click the Log Out icon to log out of the Ansible Tower web interface.
10. Add the http://materials.example.com/labs/products-review/ldap-idm.py
inventory script to the Ansible Tower instance.
10.1. Download the custom inventory script from http://materials.example.com/
labs/products-review/ldap-idm.py to workstation.
10.2. Log in to the Ansible Tower web user interface with the admin account and the
redhat password.
10.3. In the Ansible Tower web user interface, click the Settings icon, followed by
INVENTORY SCRIPTS.
10.4. Click ADD to create a inventory script. Enter IdM Custom Inventory in the NAME
field and Default in the ORGANIZATION field. In the CUSTOM SCRIPT field, enter
the contents of the ldap-idm.py script file. Click SAVE to finalize the creation of the
new custom inventory.

370 RH362-RHEL-7.4-en-1-20181003
CHAPTER 8 | Integrating Red Hat Products With IdM

11. Create a dynamic inventory using the IdM Custom Inventory custom inventory script.
11.1. In the Ansible Tower web user interface, click INVENTORIES in the top navigation
menu.
11.2. Click ADD to create a new inventory. Enter IdM Lab Hosts in the NAME field and
Default in the ORGANIZATION field. Click SAVE to finalize the creation of the new
inventory.
11.3. Click ADD GROUP to create a host group within the inventory. Enter IdM in the
NAME field and select Custom Script from the SOURCE drop-down menu. Enter IdM
Custom Inventory in the CUSTOM INVENTORY SCRIPT field. Check the box next to
Overwrite in the UPDATE OPTIONS section. Click SAVE to finalize the creation of the
new group.
11.4. Scroll down to the group list section. Click the Start sync process icon for the IdM
group.
11.5. Once the dynamic inventory sync has completed, click on the IdM group link to see the
host groups which were synced from the IdM server. Click the link for each host group
to see the hosts contained in each host group. For each host group, the list of hosts
displayed should match the list of member hosts displayed by the ipa hostgroup-
show hostgroupname command.

Evaluation
From workstation, run the lab products-review grade command to confirm the success
of this exercise. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab products-review grade

Cleanup
From workstation, run the lab products-review cleanup command to clean up this lab.

[student@workstation ~]$ lab products-review cleanup

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 371
CHAPTER 8 | Integrating Red Hat Products With IdM

SUMMARY

In this chapter, you learned:

• Centralized automount configuration in IdM and Kerberized NFS service can offer IdM users
roaming home directories on IdM clients.

• Red Hat Satellite can be configured for external authentication using IdM.

• Access to Satellite Server can be managed in IdM using HBAC.

• Satellite Server's realm feature can be used to automate the configuration of Satellite-
provisioned hosts for external authentication with IdM.

• Automembership rules automate enrollment of Satellite-provisioned hosts into IdM host groups
when defined criteria are met.

• Satellite Server's realm feature can be used to automate the configuration of Satellite-
provisioned hosts for external authentication with IdM.

• Ansible Tower can utilize IdM for LDAP authentication through queries executed by an
authorized bind account.

• IdM user information can be used to map users into Tower organizations, teams, and roles.

372 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9

INSTALLING SCALABLE IDM

GOAL Construct a resilient and scalable Identity
Management topology.

OBJECTIVES • Prepare to build a scalable IdM topology

including multiple replica servers and
replication agreements.
• Install additional IdM servers as replicas to
create a resilient topology.
• Modify the IdM topology using server roles.
• Configure and practice IdM backup and
recovery techniques.

SECTIONS • Describing IdM Topology (and Quiz)

• Building a Resilient IdM Topology (and Guided
Exercise)
• Configuring IdM Server Roles (and Guided
Exercise)
• Preparing for IdM Recovery (and Guided
Exercise)

LAB Installing Scalable IdM

RH362-RHEL-7.4-en-1-20181003 373
CHAPTER 9 | Installing Scalable IdM

DESCRIBING IDM TOPOLOGY

OBJECTIVES
After completing this section, students should be able to:

• Design a scalable IdM topology.

• Discuss replication technology.

REPLICA FUNDAMENTALS
To ensure your IdM service is resilient, you can scale it out using replicas. Put simply, a replica is
another IdM server with a copy of the data from the first IdM server. Red Hat currently supports up
to 60 replicas in an IdM topology. This section discusses what a replica is in detail, the components
used to create a resilient or distributed IdM service, and some guidelines for planning your
replication topology.

REPLICATION TOPOLOGY COMPONENTS

A resilient architecture has several components, including replicas, topology suffixes, and topology
segments.

Replicas
A replica is an IdM server belonging to the same IdM domain as the first server. It may run all or a
subset of the services running on the first server. It has the same ability to make changes to data,
because IdM uses a multimaster architecture. Changes to data are synchronized between IdM
servers using replication agreements.

Topology Sufﬁx
A topology suffix is a type of data to be synchronized between replicas. There are currently two
topology suffixes supported by IdM:

• Domain: contains the data related to identities

• CA: contains Certificate Authority data

Two replicas may synchronize one or both suffixes, depending on the services they are running.
You can show the current suffixes in use with the ipa topologysuffix-find command:

[user@demo ~]$ ipa topologysuffix-find

---------------------------
2 topology suffixes matched
---------------------------
Suffix name: ca
Managed LDAP suffix DN: o=ipaca

Suffix name: domain

Managed LDAP suffix DN: dc=lab,dc=example,dc=net
----------------------------
Number of entries returned 2
----------------------------

374 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

Topology Segment
A topology segment is created when a replication agreement defines a suffix to be synchronized
between two replicas. If both domain and CA suffixes are synchronized, then there are two
topology segments between the two replicas. Segments always synchronize data in both
directions. In a topology segment, one server will be referred to as the left node, and the other as
the right node.

Figure 9.1: Topology segments

RESILIENT TOPOLOGY GUIDELINES

There are several guidelines to consider when designing a resilient IdM topology.

Minimum of two replication agreements per server

To ensure a server is not isolated if a peer fails, configure at least two replication agreements
to different peers.

Maximum of four replication agreements per server

Creating more than four replication agreements does not noticeably increase resilience, but
can start to impact performance.

2000 to 3000 clients per server

To decide on the number of replicas to place at a specific location, include one for every 2000
to 3000 clients. Some clients may be more chatty than others depending on the applications
in use, but generally this guideline holds true.

Two replication agreements between datacenters

Configure at least two replication agreements between a pair of datacenters. Use two pairs of
servers to prevent isolation of the whole datacenter for a single server failure.

Connect datacenters to at least two others if possible

Connecting a datacenter to at least two others allows for replication in the event that an entire
site is offline.

Tight Cell
In a single location, the most resilient arrangement of servers is called a tight cell. Tight cell
uses four servers with replication agreements from each server to all other servers. This
means that each server can add one more replication agreement to another datacenter
without violating the four replication agreement maximum.

RH362-RHEL-7.4-en-1-20181003 375
CHAPTER 9 | Installing Scalable IdM

Figure 9.2: Tight cell

Figure 9.3: Datacenter replication

TOPOLOGY CONSIDERATIONS
Once the server placement and replication topology has been determined, you should also take
into account the domain level. From Red Hat Enterprise Linux 7.3 onward, the default domain level
is set to 1 during installation of the first IdM server. This is an increase from level 0, which was the
default in earlier versions of Red Hat Enterprise Linux. The primary benefit of domain level 1 is
simplified topology management.

If your IdM domain is currently at level 0, consider updating to a release of Red Hat Enterprise
Linux equal to or greater than 7.3. You can then raise your domain level, which reduces the effort
required for topology configuration.

Also of note are the tasks that can only run on a single server. The first server in the domain is
responsible for tracking certificates and keys, and updating the Certificate Revocation List. If
this server is down for an extended period, you should consider migrating these tasks to another
replica.

376 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

REFERENCES
Further information is available in the Managing Replication Topology chapter in the
Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

Further information is available in the Displaying and Raising the Domain Level
chapter in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/articles/1586893

RH362-RHEL-7.4-en-1-20181003 377
CHAPTER 9 | Installing Scalable IdM

QUIZ

IDM TOPOLOGY
Choose the correct answers to the following questions:

1. How many replication agreements does each server in a tight cell have?
a. 1
b. 2
c. 3
d. 4

2. Given three topology sufﬁxes to replicate, how many topology segments exist between
two servers in a replication agreement?
a. 1
b. 2
c. 3
d. 4
e. 5
f. 6

3. Your organization's base OS version is Red Hat Enterprise Linux 7.4. You have just
installed your ﬁrst IdM server, what is your domain level?
a. 0
b. 1
c. 2
d. 3
e. 4

378 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

SOLUTION

IDM TOPOLOGY
Choose the correct answers to the following questions:

1. How many replication agreements does each server in a tight cell have?
a. 1
b. 2
c. 3
d. 4

2. Given three topology sufﬁxes to replicate, how many topology segments exist between
two servers in a replication agreement?
a. 1
b. 2
c. 3
d. 4
e. 5
f. 6

3. Your organization's base OS version is Red Hat Enterprise Linux 7.4. You have just
installed your ﬁrst IdM server, what is your domain level?
a. 0
b. 1
c. 2
d. 3
e. 4

RH362-RHEL-7.4-en-1-20181003 379
CHAPTER 9 | Installing Scalable IdM

BUILDING A RESILIENT IDM TOPOLOGY

OBJECTIVES
After completing this section, students should be able to:

• Install a replica as a server clone.

• Install a replica as a client and promote it to a server role.

• Create a replication agreement.

REQUIREMENTS FOR INSTALLING A REPLICA

The general installation requirements for replicas are the same as for IdM servers. Make sure that
the replica server meets all prerequisites listed in the first chapter of this course.

The following conditions must also be met in addition to the general IdM server requirements:

• The replica must use the same or later version of IdM. This ensures that the configuration can be
properly copied from the server to the replica.

• Additional ports need to be open on the replica. In addition to the standard IdM server ports,
open TCP port 22 for replica setup process at domain level 0. If you have a server running on
RHEL 6 with a CA installed, also open TCP port 7389.

• A replica has the same package requirements as IdM server.

INSTALLING THE REPLICA

The procedure described in this section uses the simplified replica install introduced in Red Hat
Enterprise Linux 7.3.

A new replica can be installed in two ways:

• By promoting an existing IdM client to a replica

• By using a server that has not been enrolled in the IdM domain

To install a new replica, use the ipa-replica-install command. Additional options can be
added to customized the replica. For example, the --setup-dns option installs a replica with DNS,
and the --setup-ca installs a replica with a CA. For a complete list of available options, see the
man page for the ipa-replica-install command.

Promoting an Existing Client to a Replica

Prior to promoting an existing IdM client to a replica, you must make sure that the client is
authorized to be promoted. To promote the client to a replica, you must provide the appropriate
user's credentials. You can provide the credentials in the following ways:

• Start the replica installation process and provide the appropriate user's credentials interactively
when prompted:

[root@demo ~]# ipa-replica-install

• Before starting the installation process, use the kinit command to log in as the appropriate
user:

380 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

[root@demo ~]# kinit admin

• Add the principal name and password directly as arguments for the ipa-replica-install
command:

[root@demo ~]# ipa-replica-install \

--principal admin \
--admin-password password

If the server is a member of the ipaservers group, you are not required to provide the user's
credentials because membership in that group grants elevated privileges similar to a privileged
user's credentials.

Installing a Replica on a Machine That Is Not a Client

When using the ipa-replica-install command on a machine that has not been enrolled in
the IdM domain, that machine is first enrolled as a client and then all the replica components are
installed.

To install a new replica this way, use one of the following scenarios:

• Install using a privileged user's credentials:

The default privileged user is admin.

[root@demo ~]# ipa-replica-install \

--principal admin \
--admin-password password

• Generate and provide a random password for the client:

This method requires you to generate a random password on the server prior to installing the
replica. You do not have to provide any additional user credentials during installation.

[root@demo ~]# ipa-replica-install --password 'random_password'

By default, the installation script uses DNS discovery to determine the IdM server name that the
replica will be installed against. To manually install the replica against a particular server, add the
--server option and the --domain option to the ipa-replica-install command.

[root@demo ~]# ipa-replica-install \

--principal admin \
--admin-password password
--server idm_server_name
--domain domain_name

UNINSTALLING A REPLICA
Uninstalling a replica server instance is simple. To do it, you need to issue two commands and
modify the DNS records pointing to the name of the server that was running IdM:

1. Using a different server than the replica (you can use one of the IdM clients), issue the ipa
server-del command to delete the desired replica server from the topology:

RH362-RHEL-7.4-en-1-20181003 381
CHAPTER 9 | Installing Scalable IdM

[root@server1 ~]# ipa server-del demo.example.net

2. On the replica server (demo.example.net, in this example), issue the ipa-server-install

--uninstall command:

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

3. Remove all nameserver (NS) DNS records pointing to the replica server from all of your DNS
zones.

REPLICATION AGREEMENTS AND TOPOLOGY

SEGMENTS
Replication agreements between IdM servers govern the replication process. When two servers
have a replication agreement configured, they share their data. Replication process in IdM works
both ways: the data from the first replica is replicated to the other one as well as from the other
replica to the first. The data is replicated in both directions.

Two replicas with a replication agreement form a topology segment. Each segment consists of the
left node and a right node. The nodes represent servers in the replication agreement.

The ipa topologysegment-find can be used to display the topology segments configured for
the domain. Below is an example of a topology where domain-related data is replicated between
two servers, demo.example.com and server1.example.com.

[root@demo ~]# ipa topologysegment-find

Suffix name: domain
-----------------
1 segment matched
-----------------
Segment name: demo.example.com-to-server1.example.com
Left node: demo.example.com
Right node: server1.example.com
Connectivity: both
----------------------------
Number of entries returned 1
----------------------------

Topology Graph
IdM's web UI shows the relationships between servers in the domain using the topology graph.

To access the topology graph, log in to the Web UI. Select IPA Server → Topology → Topology
Graph. You can move the nodes by dragging the mouse.

382 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

Figure 9.4: Topology graph

Servers connected by an orange arrow are joined in a domain replication agreement. Servers
connected by a blue arrow are joined in a CA replication agreement.

Setting Up Replication
To create a topology segment between two existing IdM servers, use the ipa
topologysegment-add command. You are prompted for the following information:

• The type of topology suffix. Available types are domain or CA.

• The left node and right node: hostnames of the two servers.

• Custom name for the new segment. This is optional.

[root@demo ~]# ipa topologysegment-add

Suffix name: domain
Left node: demo.example.com
Right node: server2.example.com
Segment name [demo.example.com-to-server2.example.com]: segment_name
---------------------------
Added segment "segment_name"
---------------------------
Segment name: segment_name
Left node: demo.example.com
Right node: server2.example.com
Connectivity: both

That new segment joins the servers in a replication agreement.

Stopping Replication
In order to stop an existing replication, you must delete the corresponding replication segment. To
delete a replication segment, you need to know the segment name.

Use the ipa topologysegment-del command to remove the topology segment.

RH362-RHEL-7.4-en-1-20181003 383
CHAPTER 9 | Installing Scalable IdM

[root@demo ~]# ipa topologysegment-del

Suffix name: domain
Segment name: segment_name
-----------------------------
Deleted segment "segment_name"
-----------------------------

Re-initializing a Replica
Sometimes a re-initialization of a replica is needed. This situation may occur if a replica has been
offline for a long period of time or its database has been corrupted.

Use the ipa-replica-manage re-initialize command to re-initialize a data replication

agreement. The host on which you run the command is the re-initialized replica. To re-initialize a
certificate server replication agreement, use the ipa-csreplica-manage command.

[root@server2 ~]# ipa-replica-manage re-initialize --from demo.example.com

REFERENCES
Further information is available in the chapter on Installing and Uninstalling Identity
Management Replicas in the Linux Domain Identity, Authentication, and Policy Guide
at
https://access.redhat.com/documentation/en-US/index.html

384 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

GUIDED EXERCISE

BUILDING A RESILIENT IDM TOPOLOGY

In this exercise, you will install replicas and create a replication agreement.

OUTCOMES
You should be able to:

• Install a replica as a server clone.

• Install a replica as a client and promote it to a server role.

• Create a replication agreement.

If you have done the exercises from the previous chapter, you must reset replica1 and
replica2 virtual machines. When the reset process is finished, log in to workstation as
student using student as the password. Run the lab scale-resilient setup command to
configure the environment.

[student@workstation ~]$ lab scale-resilient setup

1. The replica1.lab.example.net server has been joined to the lab.example.net

domain as a client. From workstation VM, open a terminal and use the ssh command to
log in to the replica1 server as the student user, and then become root to install all the
packages needed for replication.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[sudo] password for student: student
[root@replica1 ~]#

Use the yum command to install the required packages.

[root@replica1 ~]# yum install ipa-server ipa-server-dns

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

2. Use nmcli command with the connection modify ipv4.dns 172.25.250.8 option
to use the DNS server running on idm.lab.example.net server.

[root@replica1 ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

[root@replica1 ~]# nmcli connection reload "System eth0"

RH362-RHEL-7.4-en-1-20181003 385
CHAPTER 9 | Installing Scalable IdM

3. Ensure that the DNS server is pointing at the IdM server.

[root@replica1 ~]# cat /etc/resolv.conf

# Generated by NetworkManager
search lab.example.net
nameserver 172.25.250.8

4. Ensure that the firewalld service is enabled and running.

[root@replica1 ~]# systemctl is-enabled firewalld

enabled
[root@replica1 ~]# systemctl is-active firewalld
active

5. Use the firewall-cmd command to allow access for the freeipa-ldap, freeipa-
ldaps, and dns services.

[root@replica1 ~]# firewall-cmd --add-service=freeipa-ldap

success
[root@replica1 ~]# firewall-cmd --add-service=freeipa-ldaps
success
[root@replica1 ~]# firewall-cmd --add-service=dns
success
[root@replica1 ~]# firewall-cmd --add-service=freeipa-ldap --permanent
success
[root@replica1 ~]# firewall-cmd --add-service=freeipa-ldaps --permanent
success
[root@replica1 ~]# firewall-cmd --add-service=dns --permanent
success

6. Verify the hostname of the system. Ensure that the hostname is in FQDN format.

[root@replica1 ~]# hostname

replica1.lab.example.net

Leave the replica1 console open and proceed to the next step.

386 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

7. By default the PTR sync option is disabled on IdM for security reasons. Because of that, the
reverse DNS record for the replica1 server is missing. Add the missing reverse DNS entry
for replica1.lab.example.net server.
On workstation, open Firefox browser and access the IdM web UI at https://
idm.lab.example.net. Log in as the admin user with RedHat123^ as password.
7.1. Go to Network Services → DNS → DNS Zones. Click the 250.25.172.in-addr.arpa.
link.
7.2. Click the Add button.
7.3. In the Add DNS Resource Record dialog window, type in 9 as the Record name. From
the Record Type drop-down list, choose PTR. In the Hostname text field, type in
replica1.lab.example.net. as the hostname.

NOTE
Take caution when typing replica1.lab.example.net. hostname; do not omit
the . at the end of the line.

7.4. Click the Add button to confirm the entry.

8. Go back to the replica1 server console. Verify the IPv4 DNS configuration for the system.
Ensure that the system has forward and reverse DNS entries.

[root@replica1 ~]# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 52:54:00:00:fa:09 brd ff:ff:ff:ff:ff:ff
inet 172.25.250.9/24 brd 172.25.250.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe00:fa09/64 scope link
valid_lft forever preferred_lft forever
[root@replica1 ~]# dig +short replica1.lab.example.net A
172.25.250.9
[root@replica1 ~]# dig +short -x 172.25.250.9
replica1.lab.example.net.

9. Use the ipa-replica-install command to install the new replica. Install this replica
with integrated DNS and certificate server.

[root@replica1 ~]# ipa-replica-install \

--principal admin \
--admin-password RedHat123^ \
--setup-dns --setup-ca --no-forwarders
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd

Run connection check to master

Connection check OK

RH362-RHEL-7.4-en-1-20181003 387
CHAPTER 9 | Installing Scalable IdM

Configuring NTP daemon (ntpd)

[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot

...output omitted...

Done configuring DNS key synchronization service (ipa-dnskeysyncd).

Restarting ipa-dnskeysyncd
Restarting named
Updating DNS system records

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

NOTE
If the ipa-replica-install command fails, it is most likely due to a wrong DNS
client configuration. Make sure that the /etc/resolv.conf file, as well as the
Ethernet interface configuration file, both point to the correct DNS server. In this
exercise, it is the idm server IP address of 172.25.250.8.

10. To test the replication process, add a new user to the environment. On replica1 server,
request a new Kerberos ticket for the admin user with RedHat123^ as password.

[root@replica1 ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

11. Use the ipa user-add idmuser11 --first=Test --last=Replication

command to add a new user to the environment.

[root@replica1 ~]# ipa user-add idmuser11 --first=Test --last=Replication

----------------------
Added user "idmuser11"
----------------------
User login: idmuser11
First name: Test
Last name: Replication
Full name: Test Replication
Display name: Test Replication
Initials: TU
Home directory: /home/idmuser11
GECOS: Test Replication
Login shell: /bin/sh
Principal name: idmuser11@LAB.EXAMPLE.NET
Principal alias: idmuser11@LAB.EXAMPLE.NET
Email address: idmuser11@lab.example.net
UID: 771500500
GID: 771500500
Password: False
Member of groups: ipausers
Kerberos keys available: False

388 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

12. From workstation, open a terminal and use SSH to log in to the idm server as the
student user, and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

On idm server, use the ipa user-show idmuser11 command to verify that the
replication process has been successful.

[root@idm ~]# ipa user-show idmuser11

User login: idmuser11
First name: Test
Last name: Replication
Full name: Test Replication
Display name: Test Replication
Initials: TU
Home directory: /home/idmuser11
GECOS: Test Replication
Login shell: /bin/sh
Principal name: idmuser11@LAB.EXAMPLE.NET
Principal alias: idmuser11@LAB.EXAMPLE.NET
Email address: idmuser11@lab.example.net
UID: 771500500
GID: 771500500
Password: False
Member of groups: ipausers
Kerberos keys available: False

13. Add another replica to the topology. This new replica is not yet a member of the
lab.example.net domain.
In the lab.example.net DNS zone, create a PTR record pointing at the
replica2.lab.example.net, using the 172.25.250.10 IP address.
On workstation, open the Firefox browser and access the IdM web UI at https://
idm.lab.example.net. Log in as the admin user with redhat as password.
13.1. Go to Network Services → DNS → DNS Zones. Click the 250.25.172.in-addr.arpa.
link.
13.2. Click the Add button.
13.3. In the newly opened Add DNS Resource Record dialog window, type in 10 as the
Record name. From the Record Type drop-down list, choose PTR. In the Hostname
text field, type in replica2.lab.example.net. as the hostname.

NOTE
Do not omit the . at the end of the line when typing the
replica2.lab.example.net. hostname.

13.4. On workstation, open a terminal and use SSH to log in to the replica2 server as
the student user, and then become root.

[student@workstation ~]$ ssh replica2

[student@replica2 ~]$ sudo -i

RH362-RHEL-7.4-en-1-20181003 389
CHAPTER 9 | Installing Scalable IdM

[sudo] password for student: student

[root@replica2 ~]#

13.5. Install the required packages.

[root@replica2 ~]# yum install ipa-client ipa-server ipa-server-dns

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

13.6. Use the nmcli command with the connection modify ipv4.dns
172.25.250.8 option to use the DNS server running on the
idm.lab.example.net server.

[root@replica2 ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

[root@replica2 ~]# nmcli connection reload "System eth0"
[root@replica2 ~]# systemctl restart NetworkManager

13.7. Ensure that the firewalld service is enabled and running.

[root@replica2 ~]# systemctl is-enabled firewalld

enabled
[root@replica2 ~]# systemctl is-active firewalld
active

13.8. Use the firewall-cmd command to allow access for the freeipa-ldap,
freeipa-ldaps, and dns services.

[root@replica2 ~]# firewall-cmd --add-service=freeipa-ldap

success
[root@replica2 ~]# firewall-cmd --add-service=freeipa-ldaps
success
[root@replica2 ~]# firewall-cmd --add-service=dns
success
[root@replica2 ~]# firewall-cmd --add-service=freeipa-ldap --permanent
success
[root@replica2 ~]# firewall-cmd --add-service=freeipa-ldaps --permanent
success
[root@replica2 ~]# firewall-cmd --add-service=dns --permanent
success

13.9. Ensure that the /etc/resolv.conf file on replica2 points to the correct DNS
server with the IP address of 172.25.250.8.

[root@replica2 ~]# vim /etc/resolv.conf

# Generated by NetworkManager
search lab.example.net example.net

390 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

nameserver 172.25.250.8

13.10. Use the ipa-replica-install command to install the new replica. Enroll the
replica2.lab.example.net server to the idm.lab.example.net master
server.

[root@replica2 ~]# ipa-replica-install --principal admin \

--admin-password RedHat123^ \
--server=idm.lab.example.net \
--domain=lab.example.net

...output omitted...

[7/9]: stopping directory server

[8/9]: restoring configuration
[9/9]: starting directory server
Done.
Restarting the KDC

NOTE
If the ipa-replica-install command fails, it is most likely due to an incorrect
DNS client configuration. Make sure that the /etc/resolv.conf file, as well as
the Ethernet interface configuration file, both point to the correct DNS server. In this
exercise, this is the idm server IP address of 172.25.250.8.

Cleanup
From workstation, run the lab scale-resilient cleanup command to clean up this
exercise.

[student@workstation ~]$ lab scale-resilient cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 391
CHAPTER 9 | Installing Scalable IdM

CONFIGURING IDM SERVER ROLES

OBJECTIVES
After completing this section, students should be able to:

• Promote a replica server to be a master.

• Delete a server from the topology.

• Change server roles.

SERVER ROLES
Each server in the topology can perform multiple roles. A role that the server performs is based on
the functionality it can perform within the topology. Services installed on each replica determine
that server's role in the topology. For example, a replica may have one or all of the following roles:

• Certificate Authority (CA) server

• DNS server
• Key Recovery Authority (KRA) server
• Active Directory trust agent or trust controller

Some of the roles can be added at any time. It is a good practice to install the CA server or the
DNS server role at the moment of installing the replica. This way of setting up the replica server
simplifies administration right from the start. It adds all the required DNS entries, as well as
establishes the topology with the desired server roles.

The full list of supported server roles can be accessed in the web UI under IPA Server → Topology
→ Server Roles.

Figure 9.5: Server roles

• absent: no server in the topology is performing that particular role

• enabled: one or more servers are performing that role in the topology

From the command line, the same information can be accessed using the ipa config-show
command:

392 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

[root@demo ~]# ipa config-show

...output omitted...
IPA masters: demo.example.com
IPA CA servers: demo.example.com
IPA NTP servers: demo.example.com
IPA CA renewal master: demo.example.com
IPA master capable of PKINIT: demo.example.com
Domain resolution order: example.com

To list the roles that a particular server has in the topology, use the ipa server-show command:

[root@demo ~]# ipa server-show demo.example.com

Server name: demo.example.com
Managed suffixes: domain, ca
Min domain level: 0
Max domain level: 1
Enabled server roles: CA server, DNS server, NTP server

In the example above, the server has the CA server, DNS server, and NTP server roles
enabled.

To find all servers that have a specific role enabled, use the ipa server-find --servrole
"server_role" command.

[root@demo ~]# ipa server-find --servrole "DNS server"

---------------------
2 IPA servers matched
---------------------
Server name: demo.example.com
Min domain level: 0
Max domain level: 1

Server name: server1.example.com

Min domain level: 0
Max domain level: 1
----------------------------
Number of entries returned 2
----------------------------

Adding a Role
Roles, such as the DNS server role, can be added to an existing replica at any time. Adding a new
role requires installing new services on the replica server.

This is a procedure for adding a role to an existing replica server. To add the DNS role to an existing
replica server, use the ipa-dns-install command on that server:

[root@server1 ~]# ipa-dns-install

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will setup DNS for the IPA Server.

This includes:
* Configure DNS (bind)

RH362-RHEL-7.4-en-1-20181003 393
CHAPTER 9 | Installing Scalable IdM

* Configure SoftHSM (required by DNSSEC)

* Configure ipa-dnskeysyncd (required by DNSSEC)

NOTE: DNSSEC zone signing is not enabled by default

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

Do you want to configure DNS forwarders? [yes]: no

Do you want to search for missing reverse zones? [yes]: Enter

...output omitted...

Updating DNS system records

==============================================================================
Setup complete

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

You must make sure these network ports are open:

TCP Ports:
* 53: bind
UDP Ports:
* 53: bind

PROMOTING A REPLICA TO A MASTER CA SERVER

The server that manages the renewal of CA subsystem certificates and generates certificate
revocation lists (CRLs) is by default the master CA server, which is the initial server from which
replicas are created.

In case the master CA server needs to be decommissioned or taken offline, you must promote
another CA server to take its place as the new CA renewal master. Follow this procedure to promote
a CA server to be the new CA renewal master in your topology:

1. Configure the CA subsystem certificate renewal on the replica server.

2. Configure the CRLs generation on the replica server.

3. Test the new configuration before decommissioning the previous master CA server.

Changing the Current CA Renewal Master

Log in to the web UI and go to IPA Server → Configuration. From the IPA CA renewal master drop-
down list, select the new CA renewal master.

394 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

Figure 9.6: Changing the current CA renewal master

The same change can be performed from the command line by using the ipa config-mod --
ca-renewal-master-server.

[root@server1 ~]# ipa config-mod --ca-renewal-master-server server1.example.com

...output omitted...
IPA CA renewal master: server1.example.com

The output confirms that the change was successful.

Changing Which Server Generates CRLs

This change requires you to stop the CRL generation on the current master, and then to enable it
on the other available replica.

1. On the CRL generation master server, stop the CA service.

[root@demo ~]# systemctl stop pki-tomcatd@pki-tomcat.service

2. On the master server, open the /etc/pki/pki-tomcat/ca/CS.cfg file and set the
required parameters to false to disable the CRL generation.

[root@demo ~]# vim /etc/pki/pki-tomcat/ca/CS.cfg

...output omitted...
ca.crl.MasterCRL.enableCRLCache=false
ca.crl.MasterCRL.enableCRLUpdates=false
...output omitted...

3. Start the CA service.

[root@demo ~]# systemctl start pki-tomcatd@pki-tomcat.service

4. Open the /etc/httpd/conf.d/ipa-pki-proxy.conf file and uncomment the

RewriteRule argument to configure Apache to redirect CRL requests to the new master.

[root@demo ~]# vim /etc/httpd/conf.d/ipa-pki-proxy.conf

...output omitted...
# Only enable this on servers that are not generating a CRL
RewriteRule ^/ipa/crl/MasterCRL.bin
https://server.example.com/ca/ee/ca/getCRL?op=getCRL&rlIssuingPoint=MasterCRL
[L,R=301,NC]
...output omitted...

RH362-RHEL-7.4-en-1-20181003 395
CHAPTER 9 | Installing Scalable IdM

5. Restart Apache.

[root@demo ~]# systemctl restart httpd.service

Configure the replica server to generate CRLs:

1. Stop the CA service.

[root@server ~]# systemctl stop pki-tomcatd@pki-tomcat.service

2. Open the /etc/pki/pki-tomcat/ca/CS.cfg file and set the required parameters to

false to enable the CRL generation.

[root@server ~]# vim /etc/pki/pki-tomcat/ca/CS.cfg

...output omitted...
ca.crl.MasterCRL.enableCRLCache=true
ca.crl.MasterCRL.enableCRLUpdates=true
...output omitted...

3. Start the CA service.

[root@server ~]# systemctl start pki-tomcatd@pki-tomcat.service

4. Open the /etc/httpd/conf.d/ipa-pki-proxy.conf file and comment out the

RewriteRule argument to configure Apache to disable redirecting CRL requests.

[root@demo ~]# vim /etc/httpd/conf.d/ipa-pki-proxy.conf

...output omitted...
#RewriteRule ^/ipa/crl/MasterCRL.bin
https://server.example.com/ca/ee/ca/getCRL?op=getCRL&rlIssuingPoint=MasterCRL
[L,R=301,NC]
...output omitted...

5. Restart Apache.

[root@server ~]# systemctl restart httpd.service

6. Make sure the /var/lib/ipa/pki-ca/publish/MasterCRL.bin file exists on the new

master CA server. If the file exists, the new master CA is configured correctly and the previous
CA master can be safely decommissioned.

DELETING A REPLICA FROM THE TOPOLOGY

Removing a replica server from the topology is an irreversible action. The only way to introduce a
deleted replica back into the topology is to install a new replica on that server.

The below steps outline the procedure of deleting a replica from the topology:

1. On one of the other servers in the topology, run the ipa server-del command to remove
the replica server.

[root@demo ~]# ipa server-del

Server name: server1.example.com

396 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

Removing server1.example.com from replication topology, please wait...

----------------------------------------------------------
Deleted IPA server "server1.example.com"
----------------------------------------------------------

2. On the removed replica server, run the ipa-server-install --uninstall to uninstall

the IdM server components from the machine.

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

This is a NON REVERSIBLE operation and will delete all data and configuration!
It is highly recommended to take a backup of existing data and configuration using
ipa-backup utility before proceeding.

Are you sure you want to continue with the uninstall procedure? [no]: yes

Updating DNS system records

---------------------------------------------
Deleted IPA server "server1.example.com"
---------------------------------------------
Shutting down all IPA services
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa-custodia
Unconfiguring ipa-otpd
Removing IPA client configuration
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/
sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Systemwide CA database updated.
Client uninstall complete.
The ipa-client-install command was successful

3. On a server in the topology, run the ipa-replica-manage list-ruv command to ensure

that the replica server has been removed from the Replica Update Vectors LDAP
entries.

[root@demo ~]# ipa-replica-manage list-ruv

Directory Manager password: password

Replica Update Vectors:

demo.example.com:389: 4
server1.example.com:389: 9

RH362-RHEL-7.4-en-1-20181003 397
CHAPTER 9 | Installing Scalable IdM

server2.example.com:389: 10
Certificate Server Replica Update Vectors:
demo.example.com:389: 6

4. If the replica server is still present in the Replica Update Vectors list, use the ipa-
replica-manage clean-ruv RUV_ID command to remove that server from LDAP entries.
Use the server Replica ID from the previous step as the RUV_ID argument for the cleanup
command.

[root@demo ~]# ipa-replica-manage clean-ruv 9

Directory Manager password: password

Clean the Replication Update Vector for server1.example.com:389

Cleaning the wrong replica ID will cause that server to no

longer replicate so it may miss updates while the process
is running. It would need to be re-initialize to maintain
consistency. Be very careful.
Continue to clean? [no]: yes
Background task created to clean replication data. This may take a while.
Cleanup task created

REFERENCES
Further information is available in the chapter on Managing Server Roles in the Linux
Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-US/index.html

398 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

GUIDED EXERCISE

CONFIGURING IDM SERVER ROLES

In this exercise, you will configure IdM server roles.

OUTCOMES
You should be able to:

• Promote a replica to be a master.

• Change server roles.

• Delete a server from the topology.

For this exercise to work, you must successfully complete the previous one. Log in to
workstation as student using student as the password. Run the lab scale-roles setup
command to configure the environment.

[student@workstation ~]$ lab scale-roles setup

1. Start this exercise by reviewing current replication topology. From the workstation
VM, open a terminal and use the ssh command to log in to the replica1 server as the
student user, and then become root.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[sudo] password for student: student
[root@replica1 ~]#

2. On the replica1 server, request a new Kerberos ticket for the admin user, with
RedHat123^ as password.

[root@replica1 ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3. Use the ipa-replica-manage list command, to list all replicas in the replication
topology.

[root@replica1 ~]# ipa-replica-manage list

replica2.lab.example.net: master
idm.lab.example.net: master
replica1.lab.example.net: master

4. Use the command from the previous step with the replica1.lab.example.net server
name as argument to list the replication agreements.

RH362-RHEL-7.4-en-1-20181003 399
CHAPTER 9 | Installing Scalable IdM

[root@replica1 ~]# ipa-replica-manage list replica1.lab.example.net

idm.lab.example.net: replica

Notice that the output shows only the idm.lab.example.net server. That is correct,
because there is no replication agreement between replica1 and replica2 server.

5. Use the ipa-replica-manage list command with the replica2.lab.example.net

sever name as argument to list the replication agreements for that server.

[root@replica1 ~]# ipa-replica-manage list replica2.lab.example.net

idm.lab.example.net: replica

The output also shows only idm.lab.example.net server.

6. Use the ipa-replica-manage list command with the idm.lab.example.net sever

name as argument to list the replication agreements for that server.

[root@replica1 ~]# ipa-replica-manage list idm.lab.example.net

replica1.lab.example.net: replica
replica2.lab.example.net: replica

This output differs from the previous ones because the idm.lab.example.net
server has replication agreements with both replica1.lab.example.net and
replica2.lab.example.net servers.

7. Use the ipa topologysegment-find command to display the current topology

segments configured for the domain. When prompted for the Suffix name:, type in
domain.

[root@replica1 ~]# ipa topologysegment-find

Suffix name: domain
------------------
2 segments matched
------------------
Segment name: idm.lab.example.net-to-replica1.lab.example.net
Left node: idm.lab.example.net
Right node: replica1.lab.example.net
Connectivity: both

Segment name: idm.lab.example.net-to-replica2.lab.example.net

Left node: idm.lab.example.net
Right node: replica2.lab.example.net
Connectivity: both
----------------------------
Number of entries returned 2
----------------------------

The output illustrates the domain-related topology segments in your environment.

400 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

8. Use the ipa topologysegment-add command to create a topology segment for the
replica1.lab.example.net and replica2.lab.example.net servers.
When prompted for the Segment name, type in domain.

[root@replica1 ~]# ipa topologysegment-add

Suffix name: domain
Left node: replica1.lab.example.net
Right node: replica2.lab.example.net
Segment name [replica1.lab.example.net-to-replica2.lab.example.net]: Enter
--------------------------------------------------------------------
Added segment "replica1.lab.example.net-to-replica2.lab.example.net"
--------------------------------------------------------------------
Segment name: replica1.lab.example.net-to-replica2.lab.example.net
Left node: replica1.lab.example.net
Right node: replica2.lab.example.net
Connectivity: both

9. Use the ipa topologysegment-find command to display the new topology segments
configured for the domain. When prompted for the Suffix name, type in domain.

[root@replica1 ~]# ipa topologysegment-find

Suffix name: domain
------------------
3 segments matched
------------------
Segment name: idm.lab.example.net-to-replica1.lab.example.net
Left node: idm.lab.example.net
Right node: replica1.lab.example.net
Connectivity: both

Segment name: idm.lab.example.net-to-replica2.lab.example.net

Left node: idm.lab.example.net
Right node: replica2.lab.example.net
Connectivity: both

Segment name: replica1.lab.example.net-to-replica2.lab.example.net

Left node: replica1.lab.example.net
Right node: replica2.lab.example.net
Connectivity: both
----------------------------
Number of entries returned 3
----------------------------

Your new configuration allows replication of the domain data between all three servers.

10. Use the dig SRV _ldap._tcp.lab.example.net command to list the _ldap._tcp
records in the lab.example.net domain.

[root@replica1 ~]# dig SRV _ldap._tcp.lab.example.net

...output omitted...

_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 replica2.lab.example.net.

_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 idm.lab.example.net.
_ldap._tcp.lab.example.net. 86400 IN SRV 0 100 389 replica1.lab.example.net.

RH362-RHEL-7.4-en-1-20181003 401
CHAPTER 9 | Installing Scalable IdM

...output omitted...

Notice the three _ldap._tcp.lab.example.net records, with the same values, pointing
to three different servers. This change was made during the creation of the new replicas.
When a new replica is installed and added to the environment, the installation process
automatically creates all the necessary DNS changes. The new configuration allows clients
to join and use the domain no matter which one of the three servers is accessible.

11. Use the ipa config-show command to access information about the current domain
configuration.

[root@replica1 ~]# ipa config-show

Maximum username length: 32
Home directory base: /home
Default shell: /bin/sh
Default users group: ipausers
Default e-mail domain: lab.example.net
Search time limit: 2
Search size limit: 100
User search fields: uid,givenname,sn,telephonenumber,ou,title
Group search fields: cn,description
Enable migration mode: FALSE
Certificate Subject base: O=LAB.EXAMPLE.NET
Password Expiration Notification (days): 4
Password plugin features: AllowNThash, KDC:Disable Last Success
SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-
s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023
Default PAC types: MS-PAC, nfs:NONE
IPA masters: idm.lab.example.net, replica1.lab.example.net,
replica2.lab.example.net
IPA CA servers: idm.lab.example.net, replica1.lab.example.net
IPA NTP servers: idm.lab.example.net, replica1.lab.example.net,
replica2.lab.example.net
IPA CA renewal master: idm.lab.example.net
IPA master capable of PKINIT: idm.lab.example.net, replica1.lab.example.net
Domain resolution order: lab.example.net:example.net

Notice the different roles all the existing servers have in the environment. For example, both
idm.lab.example.net and replica1.lab.example.net servers are both the domain
CA servers, but only the idm.lab.example.net server is the CA renewal master.

12. Use the ipa server-show command to list the roles that the
replica1.lab.example.net server has in your environment.

[root@replica1 ~]# ipa server-show replica1.lab.example.net

Server name: replica1.lab.example.net
Managed suffixes: domain, ca
Min domain level: 0
Max domain level: 1
Enabled server roles: CA server, DNS server, NTP server

That server has the CA server, DNS server, and NTP server roles enabled.

402 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

13. Use the ipa server-find --servrole "DNS server" command to find all the
servers that have the DNS server role enabled.

[root@replica1 ~]# ipa server-find --servrole "DNS server"

---------------------
2 IPA servers matched
---------------------
Server name: idm.lab.example.net
Min domain level: 0
Max domain level: 1

Server name: replica1.lab.example.net

Min domain level: 0
Max domain level: 1
----------------------------
Number of entries returned 2
----------------------------

The replica2.lab.example.net server is not on that list because you have installed it
without the DNS, so it has no DNS server role.

14. From the workstation VM, open a terminal and use the ssh command to log in to the
replica2 server as the student user, and then become root.

[student@workstation ~]$ ssh replica2

[student@replica2 ~]$ sudo -i
[sudo] password for student: student
[root@replica2 ~]#

15. You can add a role to a server at any time. Before you add the new role, use the ipa-
server-upgrade command.

[root@replica2 ~]# ipa-server-upgrade

...output omitted...
CA is not configured
[Ensuring presence of included profiles]
CA is not configured
[Add default CA ACL]
[Setup PKINIT]
The IPA services were upgraded
The ipa-server-upgrade command was successful

16. Use the ipa-dns-install command to add the DNS role to the
replica2.lab.example.net server.

[root@replica2 ~]# ipa-dns-install

This includes:
* Configure DNS (bind)
* Configure SoftHSM (required by DNSSEC)

RH362-RHEL-7.4-en-1-20181003 403
CHAPTER 9 | Installing Scalable IdM

* Configure ipa-dnskeysyncd (required by DNSSEC)

NOTE: DNSSEC zone signing is not enabled by default

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

Do you want to configure DNS forwarders? [yes]: no

Do you want to search for missing reverse zones? [yes]: Enter

...output omitted...

Updating DNS system records

==============================================================================
Setup complete

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

You must make sure these network ports are open:

TCP Ports:
* 53: bind
UDP Ports:
* 53: bind

17. On the replica2 server, request a new Kerberos ticket for the admin user with
RedHat123^ as password.

[root@replica2 ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

18. Use the ipa server-find --servrole "DNS server" command to find all the
servers that have the DNS server role enabled.

[root@replica2 ~]# ipa server-find --servrole "DNS server"

---------------------
3 IPA servers matched
---------------------
Server name: idm.lab.example.net
Min domain level: 0
Max domain level: 1

Server name: replica1.lab.example.net

Min domain level: 0
Max domain level: 1

Server name: replica2.lab.example.net

Min domain level: 0
Max domain level: 1
----------------------------
Number of entries returned 3

404 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

----------------------------

Notice that the DNS role has been added to the replica2.lab.example.net server.

19. To complete your setup of a resilient environment, you must add a trust agent. The
idm.lab.example.net server is the AD trust controller in your environment. From
the workstation VM, open a terminal and use the ssh command to log in to the idm
server as the student user, and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

20. Use the ipa-adtrust-install --add-agents command to configure the

replica1.lab.example.net server as a trust agent.

[root@idm ~]# ipa-adtrust-install --add-agents

...output omitted...

Configuring cross-realm trusts for IPA server requires password for user 'admin'.
This user is a regular system account used for IPA server administration.

admin password: RedHat123^

IPA generated smb.conf detected.

Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with
trusted users.

Enable trusted domains support in slapi-nis? [no]: yes

...output omitted...

Do you want to run the ipa-sidgen taks? [no]: yes

The following operations may take some minutes to complete.

Please wait until the prompt is returned.

IPA master [replica1.lab.example.net]? [no]: yes

IPA master [replica2.lab.example.net]? [no]: no

WARNING: you MUST restart (e.g. ipactl restart) the following IPA masters in
order to activate them to serve information about users from trusted forests:

replica1.lab.example.net

=============================================================================
Setup complete

You must make sure these network ports are open:

TCP Ports:

RH362-RHEL-7.4-en-1-20181003 405
CHAPTER 9 | Installing Scalable IdM

* 135: epmap
* 138: netbios-dgm
* 139: netbios-ssn
* 445: microsoft-ds
* 1024..1300: epmap listener range
* 3268: msft-gc
UDP Ports:
* 138: netbios-dgm
* 139: netbios-ssn
* 389: (C)LDAP
* 445: microsoft-ds

See the ipa-adtrust-install(1) man page for more details

=============================================================================

21. On the replica1.lab.example.net server, use the ipactl restart command to

restart the IdM services.

[root@replica1 ~]# ipactl restart

22. Use the ipa server-find --servrole "AD trust agent" command, to find all
trust agents.

[root@replica1 ~]# ipa server-find --servrole "AD trust agent"

---------------------
2 IPA servers matched
---------------------
Server name: idm.lab.example.net
Min domain level: 0
Max domain level: 1

Server name: replica1.lab.example.net

Min domain level: 0
Max domain level: 1
----------------------------
Number of entries returned 2
----------------------------

23. Remove the replica2.lab.example.net server from the topology. Removing a server
is an irreversible action. If you remove a server, the only way to introduce it back into the
topology is to install a new replica on the machine.
On idm.lab.example.net server, run the ipa server-del command to remove
replica2.lab.example.net server.

[root@idm ~]# ipa server-del

Server name: replica2.lab.example.net
Removing replica2.lab.example.net from replication topology, please wait...
----------------------------------------------------------
Deleted IPA server "replica2.lab.example.net"
----------------------------------------------------------

406 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

24. On the replica2.lab.example.net server, run the ipa-server-install --

uninstall to uninstall the IdM server components from the machine.

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

This is a NON REVERSIBLE operation and will delete all data and configuration!
It is highly recommended to take a backup of existing data and configuration using
ipa-backup utility before proceeding.

Are you sure you want to continue with the uninstall procedure? [no]: yes

Updating DNS system records

---------------------------------------------
Deleted IPA server "replica2.lab.example.net"
---------------------------------------------
Shutting down all IPA services
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server

Unconfiguring ipa-custodia
Unconfiguring ipa-otpd
Removing IPA client configuration
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/
sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Systemwide CA database updated.
Client uninstall complete.
The ipa-client-install command was successful

25. On idm.lab.example.net server, run the ipa-replica-manage list command

to ensure that the replica2.lab.example.net server has been removed from the
topology.

[root@idm ~]# ipa-replica-manage list

idm.lab.example.net: master
replica1.lab.example.net: master

26. On idm.lab.example.net server, run the ipa-replica-manage list-ruv command

to ensure that the replica2.lab.example.net server has been removed from the

RH362-RHEL-7.4-en-1-20181003 407
CHAPTER 9 | Installing Scalable IdM

Replica Update Vectors LDAP entries. When prompted for the Directory Manager
password, type in RedHat123^.

[root@idm ~]# ipa-replica-manage list-ruv

Directory Manager password: RedHat123^

Replica Update Vectors:

idm.lab.example.net:389: 4
replica1.lab.example.net:389: 9
replica2.lab.example.net:389: 10
Certificate Server Replica Update Vectors:
idm.lab.example.net:389: 6

27. If the replica2.lab.example.net server is present on the Replica Update

Vectors list, use the ipa-replica-manage clean-ruv 10 command to remove that
server from the LDAP entries. Use replica2.lab.example.net server Replica ID
from the previous step as argument for the cleanup command.

[root@idm ~]# ipa-replica-manage clean-ruv 10

Directory Manager password: RedHat123^

Clean the Replication Update Vector for replica2.lab.example.net:389

Cleaning the wrong replica ID will cause that server to no

Cleanup
From workstation, run the lab scale-roles cleanup command to clean up this exercise.

[student@workstation ~]$ lab scale-roles cleanup

This concludes the guided exercise.

408 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

PREPARING FOR IDM RECOVERY

OBJECTIVES
After completing this section, students should be able to:

• Configure IdM servers for backup.

• Configure the IdM topology for failover.

DISASTER SCENARIOS
Once properly implemented, Identity Management becomes one of the crucial parts of a corporate
infrastructure. As such, you must have backup and restore mechanisms in place to provide
continuous availability. Depending on the scenario, there are different possible solutions. The
easiest solution is to use the default backup and restore mechanism included with IdM. A different
approach is to create a highly available, failover-tolerant environment with the use of replica
servers.

At first, recovering from a disaster seems simple: back up data, save it, and use the saved data to
restore your environment when something goes wrong. However, IdM is usually a multi-instance
deployment, and this means that once you restore one or more servers, you might have different
versions or configurations. This is where backup and restore becomes a challenge.

Usually there are two types of disaster scenarios:

• Server Loss: the IdM environment loses one, several, or all servers and needs to get back online
as quickly as possible

• Data Loss: data was deleted and subsequently propagated to all servers because of the IdM
multimaster solution

Server Loss
The recommendation to mitigate this type of disaster is to have a redundant configuration. For
example, run two or three IdM servers in each data center and let them replicate with each other. In
this type of configuration, when one server is lost, simply create a new IdM replica from one of the
existing IdM servers and get back to a fully functional state quickly.

However, the recovery process depends on the type of server that was lost. If you have lost the first
IdM server that was installed in your environment, you have to be aware of the fact that this server
usually tracks and renews internal certificates and publishes CRLs.

If the first IdM server is lost, you must nominate another master with a full CA as the new first
master. Here are the steps required:

1. Remove all replication agreements with that lost server.

2. From your environment, choose an existing IdM server with CA installed to be the new first
master.

3. Nominate this master to be in charge of renewing certs and publishing CRLs.

4. Following the standard install procedure, deploy a new master on a new hardware.

This topology change has an impact on the clients. If the client configuration is using DNS
discovery, they automatically adapt to the topology changes. However, if the clients were

RH362-RHEL-7.4-en-1-20181003 409
CHAPTER 9 | Installing Scalable IdM

configured to explicitly connect to specific servers, their configuration must be changed to reflect
the new IdM server hostnames.

As long as the first IdM server is still available, the procedure to recover any other server is more
straightforward:

1. Remove all replication agreements with the lost server.

2. Following the standard install procedure, deploy a new master on new hardware.

In a scenario where several servers are lost at the same time, the question is whether the
deployment can be rebuilt from what is left.

If the first IdM server is still working, the procedure for recovering any other server can be followed
to rebuild the environment.

If the first IdM server is lost, and there is at least one master with CA available, follow the
procedure for establishing a new master CA server.

If there is no other master with a CA left in your environment, the deployment loses the ability to
rebuild itself from what remains. This case is a total loss scenario.

Total Infrastructure Loss

In this scenario, all IdM servers in your environment are lost, or what is left is not enough to
rebuild the environment. To recover from this scenario, it is recommended to have at least one of
your replicas (with full CA) installed in a VM. That VM can be periodically stopped to create a full
snapshot of it.

Using VM snapshots allows you to save everything in a consistent state. A backup stores only data,
not the software itself. A snapshot saves both the data and the software, which makes the recovery
procedures faster and less risky.

Recovering IdM Clients

When the IdM infrastructure is restored, the clients may need changes as well:

• IdM server hostname change: if during the restoration process, IdM server hostnames were
changed, the client configuration needs to be updated to reflect the new hostnames. In this
case, you should always verify and, as needed, update the /etc/sssd/sssd.conf and /etc/
krb5.conf files.

• Stale data: sometimes after the restoration of the infrastructure, it makes sense to purge the
SSSD cache to remove any stale data on the client.

Data Loss
Data loss cases are more difficult to recover from. As soon as a data loss situation has been
identified, you should take actions to stop data loss replication in the infrastructure. The affected
replica servers should be isolated and powered down to prevent spread of the data loss.

If the data loss has already replicated to all servers, there are two options:

• If data loss made the deployment completely dysfunctional, start over from a snapshot and make
sure there is no replication agreement between the old replicas and the new one booted from the
snapshot.

• Use the existing backup to restore the lost data. The restored entries are automatically
propagated to other masters using the standard replication process.

410 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

BACKING UP AND RESTORING IDENTITY

MANAGEMENT
Red Hat Enterprise Linux Identity Management provides utilities to manually backup and restore
the IdM system. The utility creates a directory containing all the configuration information and the
LDAP database. You should always rebuild any lost server by reinstalling it as a replica. Only when
this is not possible should you consider restoring your IdM server from a backup.

IdM has two backup options:

• Full backup: the script stops the IdM services to create a full-server backup. It creates a backup
copy of all IdM server files and the LDAP data. Because it is a raw file backup, it is performed
offline.

• Data backup: this type of backup creates only a backup copy of the LDAP data and the
changelog. It can be performed online and offline.

The backup script stores its created backups in the /var/lib/ipa/backup directory.

Creating Backup
A backup is created using the ipa-backup command as the root user.

To create a data-only backup, use the same command with the --data option. Add the --online
option if you want to create a data-only backup online.

This example demonstrates how to perform a data-only backup online:

[root@demo ~]# ipa-backup --data --online

Restoring Backup
To restore your IdM from a backup, use the ipa-restore command. You can only restore a
backup from the same host upon which the backup was originally created. It is recommended
to uninstall a server before restoring a full backup on it. Uninstalling does not remove backups
present on the IdM server.

All backup types are restored using the ipa-restore command, run as the root user. As an
argument to the ipa-restore command, provide the path of the directory where the backup is
stored. The utility detects the backup type automatically and performs the same type of restore.

The following example shows the process for restoring a full-server backup:

[root@demo ~]# ipa-restore /var/lib/ipa/backup/ipa-full-2018-05-20-04-01-04/

Directory Manager (existing master) password: password

Preparing restore from /var/lib/ipa/backup/ipa-full-2018-05-20-04-01-04/ on

demo.example.com
Performing FULL restore from FULL backup
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Disabling replication agreement on server1.example.com to demo.example.com
Disabling CA replication agreement on server1.example.com to demo.example.com
Stopping IPA services

RH362-RHEL-7.4-en-1-20181003 411
CHAPTER 9 | Installing Scalable IdM

Configuring certmonger to stop tracking system certificates for CA

Systemwide CA database updated.
Restoring files
Systemwide CA database updated.
Restoring from userRoot in EXAMPLE-COM
Restoring from ipaca in EXAMPLE-COM
Restarting GSS-proxy
Starting IPA services
Restarting SSSD
The ipa-restore command was successful

You can add the following options to the ipa-restore command:

• --data - restore date only from a full-server backup

• --online - restore the data in online mode

• --instance - specify which 389 DS instance to restore

It is recommended to reboot the server after restoring from backup.

REFERENCES
Further information is available in the chapter on Backing Up and Restoring Identity
Management in the Linux Domain Identity, Authentication, and Policy Guide at
https://access.redhat.com/documentation/en-US/index.html

412 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

GUIDED EXERCISE

PREPARING FOR IDM RECOVERY

In this exercise, you will perform a backup and a restore of IdM.

OUTCOMES
You should be able to:

• Perform a backup and restore of IdM.

• Configure failover and test recovery of IdM.

This exercise depends on the two preceding exercises. For this exercise to work you must
successfully finish them in the designed order. Log in to workstation as student using
student as the password. Run the lab scale-recovery setup command to configure the
environment.

[student@workstation ~]$ lab scale-recovery setup

1. Perform a backup of the replica1.lab.example.net server.

1.1. From workstation open a terminal and use SSH to log in to the
replica1.lab.example.net as the root user.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[sudo] password for student: student
[root@replica1 ~]#

1.2. On the replica1 server, request a new Kerberos ticket for the admin user, with
RedHat123^ as password.

[root@replica1 ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

1.3. Use the ipa-backup command to create a full-server backup.

[root@replica1 ~]# ipa-backup

Preparing backup on replica1.lab.example.net
Stopping IPA services
Backing up ipaca in LAB-EXAMPLE-NET to LDIF
Backing up userRoot in LAB-EXAMPLE-NET to LDIF
Backing up LAB-EXAMPLE-NET
Backing up files
Backed up to /var/lib/ipa/backup/ipa-full-2018-04-20-04-01-04
Starting IPA service
The ipa-backup command was successful

RH362-RHEL-7.4-en-1-20181003 413
CHAPTER 9 | Installing Scalable IdM

2. Restore the full-server backup on replica1.lab.example.net server.

2.1. On replica1.lab.example.net server, use the ipa-restore command to
restore the full-server backup. As the argument, specify the location of the backup
from the previous step. Type in the Directory Manager password of RedHat123^.

[root@replica1 ~]# ipa-restore /var/lib/ipa/backup/ipa-full-2018-04-20-04-01-04/

Directory Manager (existing master) password: RedHat123^

Preparing restore from /var/lib/ipa/backup/ipa-full-2018-04-20-04-01-04/ on

replica1.lab.example.net
Performing FULL restore from FULL backup
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Disabling replication agreement on idm.lab.example.net to replica1.lab.example.net
Disabling CA replication agreement on idm.lab.example.net to
replica1.lab.example.net
Stopping IPA services
Configuring certmonger to stop tracking system certificates for CA
Systemwide CA database updated.
Restoring files
Systemwide CA database updated.
Restoring from userRoot in LAB-EXAMPLE-NET
Restoring from ipaca in LAB-EXAMPLE-NET
Restarting GSS-proxy
Starting IPA services
Restarting SSSD
The ipa-restore command was successful

You have successfully restored the backup, but because of the possible differences
between the backup and the working master, the servers are now out of sync.

3. On the replica1.lab.example.net server, use the ipa user-add command to add a

new user.

[root@replica1 ~]# ipa user-add idmuser12 --first=Test --last=Restoration

4. From workstation, open a new SSH session to the idm server as the student user, and
then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[sudo] password for student: student
[root@idm ~]#

5. On idm server, request a new Kerberos ticket for the admin user, using RedHat123^ as
password.

[root@idm ~]# kinit admin

414 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

Password for admin@LAB.EXAMPLE.NET: RedHat123^

6. Use the ipa user-show idmuser12 command to verify the existence of the idmuser12
user. Expect an error message indicating that idmuser12 could not be found. This error is
resolved in the next step.

[root@idm ~]# ipa user-show idmuser12

ipa: ERROR: idmuser12: user not found

7. Use the ipa-replica-manage re-initialize command to reinitialize the

replica1.lab.example.net server after the restore.

[root@idm ~]# ipa-replica-manage re-initialize --from=replica1.lab.example.net

Update in progress, 3 seconds elapsed
Update succeeded

8. Use the ipa user-show idmuser12 command to verify that the date between
idm.lab.example.net and replica1.lab.example.net has been synchronized.

[root@idm ~]# ipa user-show idmuser12

User login: idmuser12
First name: Test
Last name: Restoration
Home directory: /home/idmuser12
Login shell: /bin/sh
Principal name: idmuser12@LAB.EXAMPLE.NET
Principal alias: idmuser12@LAB.EXAMPLE.NET
Email address: idmuser12@lab.example.net
UID: 1388500502
GID: 1388500502
Account disabled: False
Password: False
Member of groups: ipausers
Kerberos keys available: False

9. Your environment now has two master servers. Both of the servers can be used by the
clients at the same time. Reconfigure the client.lab.example.net server to take
advantage of the fault-tolerant environment. On idm.lab.example.net, use the ipactl
stop command to simulate an IdM server error.

[root@idm ~]# ipactl stop

Stopping ipa-dnskeysyncd Service
Stopping ipa-otpd Service
Stopping winbind Service
Stopping smb Service
Stopping pki-tomcatd Service
Stopping ntpd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping named Service
Stopping kadmin Service

RH362-RHEL-7.4-en-1-20181003 415
CHAPTER 9 | Installing Scalable IdM

Stopping krb5kdc Service

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

10. From workstation, use SSH to log in to the client server as the student user, and then
become root.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[sudo] password for student: student
[root@client ~]#

11. Add 172.25.250.9, the IP address of the replica1.lab.example.net

server, to the client.lab.example.net server DNS configuration. The
replica1.lab.example.net server acts as a second DNS server in your environment.
Use nmcli command with the connection modify +ipv4.dns 172.25.250.9
option to use the DNS server running on idm.lab.example.net server.

[root@client ~]# nmcli connection modify "System eth0" +ipv4.dns 172.25.250.9

[root@client ~]# nmcli connection reload "System eth0"
[root@client ~]# systemctl restart NetworkManager

12. If necessary, modify the /etc/resolv.conf file to ensure it has the correct DNS server
entries:

[root@client ~]# vim /etc/resolv.conf

# Generated by NetworkManager
search lab.example.net example.net
nameserver 172.25.250.8
nameserver 172.25.250.9

13. Open the /etc/sssd/sssd.conf file and add the replica1.lab.example.net server
name to the list of possible IdM servers to use.

[root@client ~]# vim /etc/sssd/sssd.conf

...output omitted...

ipa_server = _srv_, idm.lab.example.net, replica1.lab.example.net

...output omitted...

14. Use the systemctl restart sssd command to restart the SSSD service.

[root@client ~]# systemctl restart sssd

15. With the IdM services on idm.lab.example.net still stopped, use workstation to
open a new SSH session on client.lab.example.net as the idmuser05 user. The

416 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

new configuration allows the client to use one of the available IdM servers, creating a fault-
tolerant environment with multiple replicas.

[student@workstation ~]$ ssh idmuser05@client

-sh-4.2$

16. From workstation, open a new SSH session to the client.lab.example.net server,
this time as the aduser05@example.net.

[student@workstation ~]$ ssh aduser05@example.net@client

-bash-4.2$

Cleanup
From workstation, run the lab scale-recovery cleanup command to clean up this
exercise.

[student@workstation ~]$ lab scale-recovery cleanup

This concludes the guided exercise.

RH362-RHEL-7.4-en-1-20181003 417
CHAPTER 9 | Installing Scalable IdM

LAB

INSTALLING SCALABLE IDM

PERFORMANCE CHECKLIST
In this lab, you will delete a replica server and promote another server.

OUTCOMES
You should be able to:

• Delete a replica server.

• Promote a server.

For this lab to work, you must successfully finish the preceding exercises in the designed order.
After you have set up the environment as described in the preceding exercises, you must reset the
replica2.lab.example.net virtual machine to it's original state. When finished reseting, log
in to workstation as student using student as the password. Run the lab scale-review
setup command to configure the environment.

[student@workstation ~]$ lab scale-review setup

1. Delete replica1.lab.example.net server from the topology.

2. Add the required PTR resource record for the replica2.lab.example.net server with
the IP address of 172.25.250.10.
3. Ensure that the replica2.lab.example.net server has been removed from the Replica
Update Vectors LDAP entries.
4. Install and configure replica2.lab.example.net server as a replica. Configure it with
the integrated DNS role, but without the CA role.

Evaluation
From workstation, run the lab scale-review grade command to confirm the success of
this lab. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab scale-review grade

Cleanup
From workstation, run the lab scale-review cleanup command to clean up after this lab.

[student@workstation ~]$ lab scale-review cleanup

This concludes the lab.

418 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

SOLUTION

INSTALLING SCALABLE IDM

PERFORMANCE CHECKLIST
In this lab, you will delete a replica server and promote another server.

OUTCOMES
You should be able to:

• Delete a replica server.

• Promote a server.

[student@workstation ~]$ lab scale-review setup

1. Delete replica1.lab.example.net server from the topology.

From workstation, use SSH to log in to the idm.lab.example.net server. On
the idm.lab.example.net server, run the ipa server-del command to remove
replica1.lab.example.net server.

[root@idm ~]# ipa server-del

Server name: replica1.lab.example.net
Removing replica1.lab.example.net from replication topology, please wait...
----------------------------------------------------------
Deleted IPA server "replica1.lab.example.net"
----------------------------------------------------------

From workstation, use SSH to log in to the replica1.lab.example.net server. On

the replica1.lab.example.net server, run ipa-server-install --uninstall to
uninstall the IdM server components from the machine.

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

This is a NON REVERSIBLE operation and will delete all data and configuration!
It is highly recommended to take a backup of existing data and configuration using
ipa-backup utility before proceeding.

Are you sure you want to continue with the uninstall procedure? [no]: yes

Updating DNS system records

---------------------------------------------
Deleted IPA server "replica1.lab.example.net"

RH362-RHEL-7.4-en-1-20181003 419
CHAPTER 9 | Installing Scalable IdM

---------------------------------------------
Shutting down all IPA services
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server

...output omitted...
Client uninstall complete.
The ipa-client-install command was successful.

2. Add the required PTR resource record for the replica2.lab.example.net server with
the IP address of 172.25.250.10.
2.1. On workstation, open the Firefox browser and access the IdM web UI at https://
idm.lab.example.net. Log in as the admin user with RedHat123^ as password.
2.2. Go to Network Services → DNS → DNS Zones. Click the 250.25.172.in-addr.arpa.
link.
2.3. Click the Add button.
2.4. In the Add DNS Resource Record dialog window, type in 10 as the Record name.
From the Record Type drop-down list choose PTR. In the Hostname text field, type in
replica2.lab.example.net. as the hostname.

NOTE
Do not omit the . at the end of the line when typing the
replica2.lab.example.net. hostname.

2.5. Click the Add button to confirm.

3. Ensure that the replica2.lab.example.net server has been removed from the Replica
Update Vectors LDAP entries.
3.1. On idm.lab.example.net server, run the ipa-replica-manage list-ruv
command to ensure that the replica2.lab.example.net server has been
removed from the Replica Update Vectors LDAP entries. When prompted for the
Directory Manager password, type in RedHat123^.

[root@idm ~]# ipa-replica-manage list-ruv

Directory Manager password: RedHat123^

Replica Update Vectors:

idm.lab.example.net:389: 4
replica1.lab.example.net:389: 9
replica2.lab.example.net:389: 10
Certificate Server Replica Update Vectors:
idm.lab.example.net:389: 6

3.2. If the replica2.lab.example.net server is present on the Replica Update

Vectors list, use the ipa-replica-manage clean-ruv 10 command to remove

420 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

that server from the LDAP entries. Use replica2.lab.example.net server

Replica ID from the previous step as argument for the cleanup command.

[root@idm ~]# ipa-replica-manage clean-ruv 10

Directory Manager password: RedHat123^

Clean the Replication Update Vector for replica2.lab.example.net:389

Cleaning the wrong replica ID will cause that server to no

4. Install and configure replica2.lab.example.net server as a replica. Configure it with

the integrated DNS role, but without the CA role.
4.1. On workstation, open a terminal and use SSH to log in to the replica2 server as
the student user, and then become root.

[student@workstation ~]$ ssh replica2

[student@replica2 ~]$ sudo -i
[sudo] password for student: student
[root@replica2 ~]#

4.2. Ensure that the required packages are installed.

[root@replica2 ~]# yum install ipa-client ipa-server ipa-server-dns

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

4.3. Use the nmcli command with the connection modify ipv4.dns
172.25.250.8 option to use the DNS server running on the
idm.lab.example.net server.

[root@replica2 ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

[root@replica2 ~]# nmcli connection reload "System eth0"
[root@replica2 ~]# systemctl restart NetworkManager

4.4. Ensure that the firewalld service is enabled and running.

[root@replica2 ~]# systemctl is-enabled firewalld

enabled
[root@replica2 ~]# systemctl is-active firewalld
active

4.5. This step is only required if you have not already configured the firewall on
replica2.lab.example.net. Use the firewall-cmd command to allow access
for the freeipa-ldap, freeipa-ldaps, and dns services.

[root@replica2 ~]# firewall-cmd --add-service=freeipa-ldap

RH362-RHEL-7.4-en-1-20181003 421
CHAPTER 9 | Installing Scalable IdM

4.6. Use the ipa-replica-install command to install the new replica.

[root@replica2 ~]# ipa-replica-install --principal admin \

--admin-password RedHat123^

Evaluation
From workstation, run the lab scale-review grade command to confirm the success of
this lab. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab scale-review grade

Cleanup
From workstation, run the lab scale-review cleanup command to clean up after this lab.

[student@workstation ~]$ lab scale-review cleanup

This concludes the lab.

422 RH362-RHEL-7.4-en-1-20181003
CHAPTER 9 | Installing Scalable IdM

SUMMARY

In this chapter, you learned:

• Replica servers help ensure IdM service resiliency. A replica is another IdM server with a copy of
the data from the first IdM server.

An IdM replica server must belong to the same IdM domain as the first server. It may run either
all or a subset of services running on the first server. It has the same ability to make changes to
data, because IdM uses a multimaster architecture.

• Requirements for installing a replica server include using the same IdM version as the first
server, opening necessary firewall ports on the replica server used during installation, and
adhering to the same package requirements as the first IdM server.

• Replication agreements between IdM servers govern the replication process. When two servers
have a replication agreement configured, they share data. The data is replicated in both
directions.

• Server roles determine the functionality it can perform within the topology. Each server can
perform multiple roles. The services installed on each replica server determine the roles, such as
the Certificate Authority (CA) or DNS server, of that replica server.

• Means of recovery from server loss or data loss is included in IdM and is available using two
possible approaches. The easiest solution is to use the default backup and restore mechanism
included with IdM. Another approach is to create a highly available, failover environment using
replica servers. The solution you choose should consider the size of your deployment, business
needs, and security and data integrity policies.

RH362-RHEL-7.4-en-1-20181003 423
424 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10

COMPREHENSIVE REVIEW
GOAL Build a minimal, resilient Identity Management
topology to include multiple masters and an Active
Directory trust relationship, populated with a
variety of users, credentials, policies and access
rights.

OBJECTIVES • Create a trust between IdM and AD.

• Create and manage users, policies, credentials,
and roles.
• Build a multi-master IdM topology.
• Create an IdM client.

SECTIONS • Comprehensive Review

LAB • Lab: Building an Active Directory Trust

Relationship
• Lab: Building a Multi-Master IdM Topology
• Lab: Manage Red Hat Identity Management

RH362-RHEL-7.4-en-1-20181003 425
CHAPTER 10 | Comprehensive Review

COMPREHENSIVE REVIEW

OBJECTIVES
After completing this section, students should be able to review and refresh knowledge and skills
learned in Red Hat Security: Identity Management and Active Directory Integration.

REVIEWING RED HAT SECURITY: IDENTITY

MANAGEMENT AND ACTIVE DIRECTORY INTEGRATION
Before beginning the comprehensive review for this course, students should be comfortable with
the topics covered in each chapter.

Students can refer to earlier sections in the textbook for extra study.

Chapter 1, Installing Red Hat Identity Management

Describe and install Red Hat Identity Management

• Describe IdM components and architecture

• Identify Directory service needs

• Install Red Hat Identity Management

Chapter 2, Centralizing Identity Management

Explain the services running on an IdM server, discuss IdM clients, configure roaming home
directories, and explain the IdM REST API.

• Manage centralized Identity Management content in a newly-installed IdM environment.

• Implement Identity Management clients in an enterprise environment using both manual and
automated methods.

• Connect to IdM services through an API useful for administrative scripting and automation.

Chapter 3, Authenticating Identities with Kerberos

Defining the Kerberos protocol and configuring services for Kerberos authentication.

• Review the authentication process by which users obtain and validate network credentials to
gain access to services and interfaces.

• Introduce and configure network credentials for both generic and specific services.

• Configure and use Kerberos authentication from a remote system that is not an IdM client.

• Manage Kerberos ticketing policies and maintain principal credentials.

Chapter 4, Managing a Public Key Infrastructure

Manage certificate authorities, certificates and storing secrets.

• Discuss certificate architecture, structure, and the generation and use of certificates.

• Describe common tasks for managing a certificate life cycle and the securing of services with
certificates.

426 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

• Discuss secure methods for storing and managing authentication secrets.

• Configure alternate forms of authentication for specific high-security use cases.

Chapter 5, Integrating IdM with Active Directory

Creating a trust relationship with Active Directory

• Configure RHEL systems to authenticate directly with an Active Directory server.

• Configure an IdM Server to share Active Directory accounts by configuring a trust relationship.

• Configure IdM functionality to use an Active Directory environment effectively.

Chapter 6, Controlling User Access

Configuring users for authorized access to services and resources.

• Configure user life-cycle parameters and resources

• Configure user access rights using host-based and sudo authorization policies

• Discuss configuring advanced authentication mechanisms

• Configure policy management rules and administration

Chapter 7, Maintaining IdM Operations

Troubleshoot and recover Identity Management.

• Manage the DNS server component of IdM and integrate with external DNS servers.

• Describe various troubleshooting techniques for resolving authentication issues.

Chapter 8, Integrating Red Hat Products With IdM

Configure major services to share the IdM authentication database.

• Create and configure centrally managed home directories for Identity Management users.

• Configure Satellite Server to use IdM as its authentication engine and store.

• Configure Ansible Tower server to use IdM as its authentication engine and store.

Chapter 9, Installing Scalable IdM

Construct a resilient and scalable Identity Management topology.

• Prepare to build a scalable IdM topology including multiple replica servers and replication
agreements.

• Install additional IdM servers as replicas to create a resilient topology.

• Modify the IdM topology using server roles.

• Configure and practice IdM backup and recovery techniques.

RH362-RHEL-7.4-en-1-20181003 427
CHAPTER 10 | Comprehensive Review

LAB

BUILDING AN ACTIVE DIRECTORY TRUST

RELATIONSHIP

PERFORMANCE CHECKLIST
In this review, you will create an IdM one-way trust relationship to Active Directory.

OUTCOMES
You should be able to:

• Create a trust between IdM and AD.

If you did not reset classroom systems at the end of the last chapter, save any work you want to
keep from earlier exercises on those machines and reset them now.

Set up your computers for this exercise by logging in to workstation as student and running
the command:

[student@workstation ~]$ lab review-relationship setup

Instructions
The idm host has an IP address of 172.25.250.8. Red Hat IdM has been installed on the idm
system and has been configured with the following settings:

• The domain is set to lab.example.net.

• The realm is set to LAB.EXAMPLE.NET.

• Both the directory manager password and the admin superuser password is set to
RedHat123^.

• Integrated DNS service is enabled without forwarders. It hosts the 250.25.172.in-

addr.arpa. reverse zone.

The ad host runs the Windows operating system and provides an Active Directory server. It is the
primary domain controller for the example.net Active Directory domain. The Administrator
user password on ad is set to password123!.
1. Delegate the lab.example.net subdomain from the Active Directory server to the
idm.lab.example.net IdM server.
2. On idm, install the software necessary for establishing a trust from IdM to Active Directory.
3. On idm, set up the components needed to establish trust to Active Directory.
4. Reconfigure the IdM's DNS settings to accommodate the trust relationship.
5. On the IdM server, add a new DNS forward zone to the example.net domain. Use the
ad.example.net server with the IP address of 172.25.250.13 as the forwarder.
6. Establish a new trust to the Active Directory server in the example.net domain.

428 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

Evaluation
As the student user on workstation, run the lab review-relationship script with the
grade argument to confirm success on this exercise. Correct any reported failures and rerun the
script until successful.

[student@workstation ~]$ lab review-relationship grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 429
CHAPTER 10 | Comprehensive Review

SOLUTION

BUILDING AN ACTIVE DIRECTORY TRUST

RELATIONSHIP

PERFORMANCE CHECKLIST
In this review, you will create an IdM one-way trust relationship to Active Directory.

OUTCOMES
You should be able to:

• Create a trust between IdM and AD.

If you did not reset classroom systems at the end of the last chapter, save any work you want to
keep from earlier exercises on those machines and reset them now.

Set up your computers for this exercise by logging in to workstation as student and running
the command:

[student@workstation ~]$ lab review-relationship setup

Instructions
The idm host has an IP address of 172.25.250.8. Red Hat IdM has been installed on the idm
system and has been configured with the following settings:

• The domain is set to lab.example.net.

• The realm is set to LAB.EXAMPLE.NET.

• Both the directory manager password and the admin superuser password is set to
RedHat123^.

• Integrated DNS service is enabled without forwarders. It hosts the 250.25.172.in-

addr.arpa. reverse zone.

The ad host runs the Windows operating system and provides an Active Directory server. It is the
primary domain controller for the example.net Active Directory domain. The Administrator
user password on ad is set to password123!.
1. Delegate the lab.example.net subdomain from the Active Directory server to the
idm.lab.example.net IdM server.
1.1. Log in to the Active Directory server, ad, as the Administrator user with
password123! as password.
1.2. On Windows taskbar, click the Search Windows magnifying glass icon. In the Search
Windows search field, type cmd and wait for Windows to locate it.
1.3. On the Best match list, right-click the Command Prompt icon. From the displayed
menu, choose Run as administrator.
1.4. In the Administrator: Command Prompt window, type in the command to add an A
record and an NS record for the IdM domain:

430 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net idm.lab.example.net. ^
More? A 172.25.250.8

Add A Record for idm.lab.example.net at example.net

Command completed successfully.

C:\Users\administrator>dnscmd 127.0.0.1 /RecordAdd ^

More? example.net ^
More? lab.example.net. NS ^
More? idm.lab.example.net.

Add NS Record for lab.example.net at example.net

Command completed successfully.

2. On idm, install the software necessary for establishing a trust from IdM to Active Directory.
2.1. From workstation, open a new terminal and log in to the idm server as the student
user, and then become root.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[root@idm ~]#

2.2. Install the ipa-server-trust-ad package.

[root@idm ~]# yum install ipa-server-trust-ad

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Complete!

3. On idm, set up the components needed to establish trust to Active Directory.

3.1. Run the kinit admin command to authenticate and obtain Kerberos credentials.
When prompted, enter RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET: RedHat123^

3.2. Use the ipa-adtrust-install command to set up components needed to establish

trust to Active Directory.

[root@idm ~]# ipa-adtrust-install --netbios-name=LABEXAMPLE -a RedHat123^

3.3. When the warning about an existing smb.conf file appears, type yes to continue.

The log file for this installation can be found in /var/log/ipaserver-install.log

==============================================================================
This program will setup components needed to establish trust to AD domains for
the IPA Server.

RH362-RHEL-7.4-en-1-20181003 431
CHAPTER 10 | Comprehensive Review

This includes:
* Configure Samba
* Add trust related objects to IPA LDAP server

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

WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your
existing samba configuration.

Do you wish to continue? [no]: yes

3.4. Type yes to enable trusted domains support in slapi-nis.

...output omitted...
Enable trusted domains support in slapi-nis? [no]: yes

3.5. Type yes to run the ipa-sidgen task.

...output omitted...
Do you want to run the ipa-sidgen task? [no]: yes

4. Reconfigure the IdM's DNS settings to accommodate the trust relationship.

4.1. Change the IdM's DNS and search domain options.

[root@idm ~]# nmcli con mod "System eth0" ipv4.dns 127.0.0.1

[root@idm ~]# nmcli con mod "System eth0" ipv4.dns-search "lab.example.net"
[root@idm ~]# nmcli conn up "System eth0"

4.2. Edit the /etc/named.conf file and disable dnssec validation:

[root@idm ~]# vim /etc/named.conf

...output omitted...
dnssec-validation no;
...output omitted...

4.3. Restart IdM services using the ipactl restart command:

[root@idm ~]# ipactl restart

... output omitted ...

5. On the IdM server, add a new DNS forward zone to the example.net domain. Use the
ad.example.net server with the IP address of 172.25.250.13 as the forwarder.
5.1. On the IdM server, use the ipa dnsforwardzone-add command to add a DNS
forwarder for the example.net domain.

[root@idm ~]# ipa dnsforwardzone-add --skip-overlap-check example.net \

--forwarder=172.25.250.13 \

432 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

--forward-policy=only

5.2. Restart the named-pkcs11 service on the IdM server.

[root@idm ~]# systemctl restart named-pkcs11

6. Establish a new trust to the Active Directory server in the example.net domain.
6.1. On IdM server, use the ipa trust-add command to create a one-way trust
relationship with the example.net Active Directory domain. When prompted, enter
password123! as the AD Administrator password.

[root@idm ~]# ipa trust-add --type=ad example.net --admin Administrator --password

[student@workstation ~]$ lab review-relationship grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 433
CHAPTER 10 | Comprehensive Review

LAB

BUILDING A MULTI-MASTER IDM

TOPOLOGY

PERFORMANCE CHECKLIST
In this review, you will build a multi-master IdM topology and create an IdM client.

OUTCOMES
You should be able to:

• Install a replica as a server clone.

• Create a replication agreement.

• Create an IdM client.

This exercise depends on the preceding review lab. For this lab to work, you must successfully
finish the preceding review lab.

Log into workstation as student using student as the password. Run the lab review-
topology setup command to configure the environment.

[student@workstation ~]$ lab review-topology setup

1. The replica1.lab.example.net server has already been joined to the

lab.example.net domain as a client. Install the packages necessary to implement
replica1 as a replica of the Red Hat IdM instance running on the idm system.
2. Configure the firewall and DNS settings on replica1 to prepare for its implementation as a
replica of the Red Hat IdM instance running on the idm system.
3. By default, the PTR sync option is disabled on IdM for security reasons. Add the missing
reverse DNS record for the replica1.lab.example.net server.
4. Implement replica1 as a new replica of the Red Hat IdM instance running on the idm
system. Install this replica with integrated DNS and certificate server.
5. The idm.lab.example.net server is the AD trust controller in the environment.
Complete the setup of a resilient environment with the addition of a trust agent.
6. Configure the client system as an IdM client for the lab.example.net domain.

Evaluation
As the student user on workstation, run the lab review-topology grade to confirm
success on this exercise. Correct any reported failures and rerun the script until successful

[student@workstation ~]$ lab review-topology grade

This concludes the lab.

434 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

SOLUTION

BUILDING A MULTI-MASTER IDM

TOPOLOGY

PERFORMANCE CHECKLIST
In this review, you will build a multi-master IdM topology and create an IdM client.

OUTCOMES
You should be able to:

• Install a replica as a server clone.

• Create a replication agreement.

• Create an IdM client.

This exercise depends on the preceding review lab. For this lab to work, you must successfully
finish the preceding review lab.

Log into workstation as student using student as the password. Run the lab review-
topology setup command to configure the environment.

[student@workstation ~]$ lab review-topology setup

1. The replica1.lab.example.net server has already been joined to the

lab.example.net domain as a client. Install the packages necessary to implement
replica1 as a replica of the Red Hat IdM instance running on the idm system.
1.1. From the workstation VM, open a terminal and use the ssh command to log in to
the replica1 server as the student user, and then become the root user.

[student@workstation ~]$ ssh replica1

[student@replica1 ~]$ sudo -i
[root@replica1 ~]#

1.2. Use the yum command to install the required packages.

[root@replica1 ~]# yum install ipa-server ipa-server-dns

...output omitted...
Is this ok [y/d/N]: y
...output omitted...

Complete!

1.3. Use nmcli command with the connection modify ipv4.dns 172.25.250.8
option so that the DNS server running on the idm.lab.example.net server is used
for name resolution.

[root@replica1 ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

RH362-RHEL-7.4-en-1-20181003 435
CHAPTER 10 | Comprehensive Review

[root@replica1 ~]# nmcli connection reload "System eth0"

2. Configure the firewall and DNS settings on replica1 to prepare for its implementation as a
replica of the Red Hat IdM instance running on the idm system.
2.1. Ensure that the DNS server is pointing at the IdM server.

[root@replica1 ~]# cat /etc/resolv.conf

# Generated by NetworkManager
search lab.example.net example.net
nameserver 172.25.250.8

2.2. Ensure that the firewalld service is enabled and running.

[root@replica1 ~]# systemctl is-enabled firewalld

enabled
[root@replica1 ~]# systemctl is-active firewalld
active

2.3. Use the firewall-cmd command to allow access for the freeipa-ldap, freeipa-
ldaps, and dns services.

[root@replica1 ~]# firewall-cmd --add-service=freeipa-ldap

2.4. Verify the hostname of the system. Ensure that the hostname is in FQDN format.

[root@replica1 ~]# hostname

replica1.lab.example.net

436 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

3. By default, the PTR sync option is disabled on IdM for security reasons. Add the missing
reverse DNS record for the replica1.lab.example.net server.
3.1. On workstation, open the Firefox browser and access the IdM web UI at https://
idm.lab.example.net. Log in as the admin user with RedHat123^ as password.
3.2. You will encounter a certificate warning since the IdM Server is using a self-signed
certificate. Click Advanced, and then click Add Exception. Click Confirm Security
Exception to accept the self-signed certificate.
3.3. Go to Network Services → DNS → DNS Zones. Click the 250.25.172.in-addr.arpa.
link.
3.4. Click the Add button.
3.5. In the newly opened Add DNS Resource Record dialog window, type in 9 as the Record
name. Choose PTR from the Record Type drop-down list. In the Hostname text field,
type in replica1.lab.example.net. as the hostname.

NOTE
When typing the replica1.lab.example.net. hostname, do not omit the . at
the end of the name.

3.6. Click the Add button to confirm the entry.

4. Implement replica1 as a new replica of the Red Hat IdM instance running on the idm
system. Install this replica with integrated DNS and certificate server.
4.1. Use the ipa-replica-install command to install the new replica.

[root@replica1 ~]# ipa-replica-install \

--principal admin \
--admin-password RedHat123^ \
--setup-dns --setup-ca --no-forwarders
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd

Run connection check to master

Connection check OK
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot

...output omitted...

Done configuring DNS key synchronization service (ipa-dnskeysyncd).

Restarting ipa-dnskeysyncd
Restarting named
Updating DNS system records

Global DNS configuration in LDAP server is empty

You can use 'dnsconfig-mod' command to set global DNS options that

RH362-RHEL-7.4-en-1-20181003 437
CHAPTER 10 | Comprehensive Review

would override settings in local named.conf files

5. The idm.lab.example.net server is the AD trust controller in the environment.

Complete the setup of a resilient environment with the addition of a trust agent.
5.1. From the workstation VM, open a terminal and use the ssh command to log in to
the idm server as the student user, and then become the root user.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[root@idm ~]#

5.2. Use the ipa-adtrust-install --add-agents command to configure the

replica1.lab.example.net server as a trust agent.

[root@idm ~]# ipa-adtrust-install --add-agents

...output omitted...

Configuring cross-realm trusts for IPA server requires password for user 'admin'.
This user is a regular system account used for IPA server administration.

admin password: RedHat123^

IPA generated smb.conf detected.

Enable trusted domains support in slapi-nis? [no]: yes

...output omitted...

WARNING: 1 IPA masters are not yet able to serve information about users from
trusted forests.
Installer can add them to the list of IPA masters allowed to access information
about trusts.
If you choose to do so, you also need to restart LDAP service on those masters.
Refer to ipa-adtrust-install(1) man page for details.

IPA master [replica1.lab.example.net]? [no]: yes

WARNING: you MUST restart (e.g. ipactl restart) the following IPA masters in
order to activate them to serve information about users from trusted forests:

replica1.lab.example.net

=============================================================================
Setup complete

438 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

See the ipa-adtrust-install(1) man page for more details

=============================================================================

5.3. On replica1.lab.example.net server, use the ipactl restart command to

restart the IdM services.

[root@replica1 ~]# ipactl restart

6. Configure the client system as an IdM client for the lab.example.net domain.
6.1. Log in to the client VM over SSH as the student user.

[student@workstation ~]$ ssh client

[student@client ~]$ sudo -i
[root@client ~]#

6.2. Become the root user and then install the ipa-client package.

[root@client ~]# yum install ipa-client

...output omitted...
Is this ok [y/d/N]: y
...output omitted...
Installed:
ipa-client.x86_64 0:4.5.0-20.el7

Complete!

6.3. Change the client's DNS nameserver configuration to use the idm server. Use
the nmcli connection modify command to set the eth0 ipv4.dns option
to 172.25.250.8. Use the nmcli connection up command to activate the DNS
change.

[root@client ~]# nmcli connection modify "System eth0" ipv4.dns 172.25.250.8

[root@client ~]# nmcli connection up "System eth0"

6.4. Execute the ipa-client-install command, specifying the --principal, --

password, and --unattended options.

[root@client ~]# ipa-client-install \

--principal=admin \

RH362-RHEL-7.4-en-1-20181003 439
CHAPTER 10 | Comprehensive Review

--password=RedHat123^ \
--unattended
WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd

Discovery was successful!

Client hostname: client.lab.example.net
Realm: LAB.EXAMPLE.NET
DNS Domain: lab.example.net
IPA Server: idm.lab.example.net
BaseDN: dc=lab,dc=example,dc=net

Skipping synchronizing time with NTP server.

Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Issuer: CN=Certificate Authority,O=LAB.EXAMPLE.NET
Valid From: 2018-02-13 00:54:53
Valid Until: 2038-02-13 00:54:53

Enrolled in IPA realm LAB.EXAMPLE.NET

Evaluation
As the student user on workstation, run the lab review-topology grade to confirm
success on this exercise. Correct any reported failures and rerun the script until successful

[student@workstation ~]$ lab review-topology grade

This concludes the lab.

440 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

LAB

MANAGE RED HAT IDENTITY

MANAGEMENT

PERFORMANCE CHECKLIST
In this lab, you will create and manage IdM users, roles, policies, and credentials.

OUTCOMES
You should be able to:

• Create user groups and associated automembership rules.

• Define password policies.

• Create users and manage their credentials.

• Grant privileges to user accounts.

This exercise depends on the preceding review labs. For this lab to work, you must have
successfully finished the preceding review labs.
1. Create a user group, idmgroup01. Set a password policy for the new group, which requires
that the password of the group's member users be a minimum of eight characters and that
login attempts are blocked after two failed attempts. This should be the highest priority
password policy.
2. Create a new automatic group membership rule named idmgroup01. This rule should add
IdM users to the idmgroup01 group when the user names begin with the string idmuser.
3. Create a user, idmuser01, whose first name is user01, last name is idm, and email address
is idmuser01@lab.example.net. The user should authenticate with the password
redhat.
4. Delegate the user management privilege to the idmuser01 user by creating a role called
User Provisioning and adding the User Administrators privilege to the role. Grant
the idmuser01 user the privilege by adding the user to the newly created role.

Evaluation
As the student user on workstation, run the lab review-management grade to confirm
success of this exercise. Correct any reported failures and rerun the script until successful.

[student@workstation ~]$ lab review-management grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 441
CHAPTER 10 | Comprehensive Review

SOLUTION

MANAGE RED HAT IDENTITY

MANAGEMENT

PERFORMANCE CHECKLIST
In this lab, you will create and manage IdM users, roles, policies, and credentials.

OUTCOMES
You should be able to:

• Create user groups and associated automembership rules.

• Define password policies.

• Create users and manage their credentials.

• Grant privileges to user accounts.

[student@workstation ~]$ ssh idm

[student@idm ~]$ sudo -i
[root@idm ~]#

1.2. Run the kinit command to obtain a Kerberos ticket. When prompted, use
RedHat123^ as the password.

[root@idm ~]# kinit admin

Password for admin@LAB.EXAMPLE.NET:RedHat123^

1.3. On the idm server, use the ipa command with the group-add subcommand to create
the idmgroup01 group with the description "Auto Membership Group".

[root@idm ~]# ipa group-add idmgroup01 \

--desc "Auto Membership Group"
------------------------
Added group "idmgroup01"
------------------------
Group name: idmgroup01
Description: Auto Membership Group

442 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

GID: 1370600012

1.4. Define a password policy for the group. Set the password policy to require a minimum
of eight characters, and to prevent further login attempts after two failures. Make it the
top policy if other password policies also pertain to this group.

[root@idm ~]# ipa pwpolicy-add idmgroup01 \

--minlength 8 --priority 1 --maxfail 2
Group: idmgroup01
Min length: 8
Priority: 1
Max failures: 2

2. Create a new automatic group membership rule named idmgroup01. This rule should add
IdM users to the idmgroup01 group when the user names begin with the string idmuser.
2.1. Create a new automatic group membership rule for the idmgroup01 group named
idmgroup01.

[root@idm ~]# ipa automember-add idmgroup01 \

--type="group" \
--desc="Auto Member Rule for idmgroup01"
----------------------------------
Added automember rule "idmgroup01"
----------------------------------
Automember Rule: idmgroup01
Description: Auto Member Rule for idmgroup01

2.2. Run the ipa command with the automember-add-condition subcommand to

define an inclusive regular expression. The expression includes all users with a UID
beginning with idmuser.

[root@idm ~]# ipa automember-add-condition

Automember Rule: idmgroup01
Attribute Key: uid
Grouping Type: group
[Inclusive Regex]: idmuser.*
[Exclusive Regex]: [Enter]
----------------------------------
Added condition(s) to "idmgroup01"
----------------------------------
Automember Rule: idmgroup01
Description: Auto Member Rule for idmgroup01
Inclusive Regex: uid=idmuser.*
----------------------------
Number of conditions added 1
----------------------------

3. Create a user, idmuser01, whose first name is user01, last name is idm, and email address
is idmuser01@lab.example.net. The user should authenticate with the password
redhat.

[root@idm ~]# ipa user-add idmuser01 \

--first=user01 --last=idm \
--email=idmuser01@lab.example.net \

RH362-RHEL-7.4-en-1-20181003 443
CHAPTER 10 | Comprehensive Review

--password
Password: redhat
Enter Password again to verify: redhat
Added user "idmuser01"
-----------------------
User login: idmuser01
First name: user01
Last name: idm
Full name: user01 idm
Display name: user01 idm
Initials: ui
Home directory: /home/idmuser01
GECOS: user01 idm
Login shell: /bin/sh
Principal name: idmuser01@LAB.EXAMPLE.NET
Principal alias: idmuser01@LAB.EXAMPLE.NET
Email address: idmuser01@lab.example.net
UID: 1411000001
GID: 1411000001
Password: True
Member of groups: ipausers, idmgroup01
Kerberos keys available: True

4. Delegate the user management privilege to the idmuser01 user by creating a role called
User Provisioning and adding the User Administrators privilege to the role. Grant
the idmuser01 user the privilege by adding the user to the newly created role.
4.1. Create the User Provisioning role by running the ipa command with the role-
add subcommand. Give the role a description of Role for Provisioning Users.

[root@idm ~]# ipa role-add --desc "Role for Provisioning Users" \

"User Provisioning"
--------------------------------
Added role "User Provisioning"
--------------------------------
Role name: User Provisioning
Description: Role for Provisioning Users

4.2. Add the User Administrators privilege to the User Provisioning role by
running the ipa command with the role-add-privilege subcommand. The
privilege is used for creating users.

[root@idm ~]# ipa role-add-privilege "User Provisioning" \

4.3. Grant the idmuser01 user the privilege required for adding users by running the ipa
command with the role-add-member subcommand.

[root@idm ~]# ipa role-add-member "User Provisioning" \

--users=idmuser01

444 RH362-RHEL-7.4-en-1-20181003
CHAPTER 10 | Comprehensive Review

Role name: User Provisioning

Description: Role for Provisioning Users
Member users: idmuser01
Privileges: User Administrators
-------------------------
Number of members added 1
-------------------------

Evaluation
As the student user on workstation, run the lab review-management grade to confirm
success of this exercise. Correct any reported failures and rerun the script until successful.

[student@workstation ~]$ lab review-management grade

This concludes the lab.

RH362-RHEL-7.4-en-1-20181003 445
446 RH362-RHEL-7.4-en-1-20181003

Do280 4.14 Student Guide
100% (2)
Do280 4.14 Student Guide
470 pages
Rh134 9.0 Student Guide
100% (2)
Rh134 9.0 Student Guide
434 pages
Do180 4.14 Student Guide
No ratings yet
Do180 4.14 Student Guide
526 pages
Do180 4.12 Student Guide
100% (2)
Do180 4.12 Student Guide
536 pages
DO480-ACM2.4-en-0-f54b122
No ratings yet
DO480-ACM2.4-en-0-f54b122
216 pages
Red Hat Open Shift DO280 Student Guide
100% (3)
Red Hat Open Shift DO280 Student Guide
474 pages
RH342 RHEL8.4 en 1 20211202
No ratings yet
RH342 RHEL8.4 en 1 20211202
492 pages
Do374 2.2 Student Guide (1)
No ratings yet
Do374 2.2 Student Guide (1)
534 pages
rh124 9.0 Student Guide
67% (3)
rh124 9.0 Student Guide
672 pages
Red Hat System Administration II RH134 9.0 - Student - Ashish Lingayat, Bernardo Gargallo, Ed Parenti, Jacob - 2023 - Anna's Archive
100% (1)
Red Hat System Administration II RH134 9.0 - Student - Ashish Lingayat, Bernardo Gargallo, Ed Parenti, Jacob - 2023 - Anna's Archive
438 pages
InstructorGuides - RH134 RHEL9.0 en 2 20220609 IG
100% (4)
InstructorGuides - RH134 RHEL9.0 en 2 20220609 IG
64 pages
ad248-7-student-guide
100% (1)
ad248-7-student-guide
698 pages
Do417 2.8 Student Guide
No ratings yet
Do417 2.8 Student Guide
600 pages
EX415 Exam Dump
No ratings yet
EX415 Exam Dump
7 pages
Cl260 5.0 Student Guide
100% (1)
Cl260 5.0 Student Guide
566 pages
Rh124 9.0 Student Guide
0% (1)
Rh124 9.0 Student Guide
596 pages
Do101 4.6 Student Guide
100% (1)
Do101 4.6 Student Guide
194 pages
Courses RH403
No ratings yet
Courses RH403
3 pages
RHCE RH294 Syllabus
No ratings yet
RHCE RH294 Syllabus
5 pages
Openstack Admin2 CL210 RHOSP10.1 en 2 20171006
No ratings yet
Openstack Admin2 CL210 RHOSP10.1 en 2 20171006
454 pages
EX403 Study Notes
No ratings yet
EX403 Study Notes
7 pages
rh354 8.0 Student Guide
100% (1)
rh354 8.0 Student Guide
218 pages
Do400 4.6 Student Guide
100% (2)
Do400 4.6 Student Guide
520 pages
RH342
No ratings yet
RH342
390 pages
LAB MANUAL-SUSE Linux Enterprise Server Administration - LMS
No ratings yet
LAB MANUAL-SUSE Linux Enterprise Server Administration - LMS
167 pages
Common Ports Cheat Sheet
No ratings yet
Common Ports Cheat Sheet
10 pages
Red Hat RH423 Red Hat Enterprise Directory Services and Authentication RHEL 5.1
100% (2)
Red Hat RH423 Red Hat Enterprise Directory Services and Authentication RHEL 5.1
435 pages
Red Hat Openstack Administration I: Core Operations For Cloud Operators
0% (1)
Red Hat Openstack Administration I: Core Operations For Cloud Operators
4 pages
Red Hat Security (RH415)
0% (3)
Red Hat Security (RH415)
1 page
RH442 RHEL7 en 2 20150227 Slides
100% (2)
RH442 RHEL7 en 2 20150227 Slides
206 pages
RH436-RHEL7 - High Availability Clustering PDF
100% (1)
RH436-RHEL7 - High Availability Clustering PDF
320 pages
RHEL - v8 RH199 (Rapid Track) PDF
67% (3)
RHEL - v8 RH199 (Rapid Track) PDF
613 pages
RH299 RHEL7 en 1 20141208 Slides
100% (1)
RH299 RHEL7 en 1 20141208 Slides
107 pages
Jb371 7.0 Student Guide
No ratings yet
Jb371 7.0 Student Guide
244 pages
Do101x-Rhocp4 6
No ratings yet
Do101x-Rhocp4 6
248 pages
Do240 2.11 Student Guide
No ratings yet
Do240 2.11 Student Guide
228 pages
Foundations of Red Hat Cloud-Native
No ratings yet
Foundations of Red Hat Cloud-Native
60 pages
jb283 1.0 Student Guide
100% (1)
jb283 1.0 Student Guide
414 pages
Do285 4.5 Student Guide
100% (1)
Do285 4.5 Student Guide
596 pages
Rh294 8.0 Student Guide
No ratings yet
Rh294 8.0 Student Guide
534 pages
Rhcsa Containers
No ratings yet
Rhcsa Containers
84 pages
Ad221 7.10 Student Guide
No ratings yet
Ad221 7.10 Student Guide
246 pages
Course Updates
No ratings yet
Course Updates
35 pages
OpenShift AI267-2.8 Syllabus
0% (1)
OpenShift AI267-2.8 Syllabus
3 pages
Red Hat Security: Linux in Physical, Virtual and Cloud (RH415)
No ratings yet
Red Hat Security: Linux in Physical, Virtual and Cloud (RH415)
10 pages
PDF Rh415 Troubleshooting Notes Compress
No ratings yet
PDF Rh415 Troubleshooting Notes Compress
14 pages
InstructorGuides RH134 RHEL8.0
100% (1)
InstructorGuides RH134 RHEL8.0
66 pages
Cloud-Native Development With OpenShift and Kubernetes
100% (2)
Cloud-Native Development With OpenShift and Kubernetes
156 pages
RH342 Study Sheet: System Boot
No ratings yet
RH342 Study Sheet: System Boot
5 pages
Open Shift - Trainning and Certification Book
No ratings yet
Open Shift - Trainning and Certification Book
560 pages
JB183 EAP7.0 en 2 20180124 IG 1 PDF
No ratings yet
JB183 EAP7.0 en 2 20180124 IG 1 PDF
78 pages
Jb463 6.3 Student Guide
No ratings yet
Jb463 6.3 Student Guide
282 pages
Ansible Ex407 Slides - 1531395006
No ratings yet
Ansible Ex407 Slides - 1531395006
62 pages
LFS201 Labs - V2020 06 11
100% (2)
LFS201 Labs - V2020 06 11
164 pages
IBM CEPH Storage
No ratings yet
IBM CEPH Storage
180 pages
Red Hat RHCSA 9 (EX200) Capsules Certification Guide
From Everand
Red Hat RHCSA 9 (EX200) Capsules Certification Guide
Waleed Hassan
5/5 (1)
Summit IdM Lab User Guide 2015
100% (1)
Summit IdM Lab User Guide 2015
39 pages
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
Cybersecurity for Executives: A Guide to Protecting Your Business
From Everand
Cybersecurity for Executives: A Guide to Protecting Your Business
Matthew C. Smith
No ratings yet
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
From Everand
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
Jay Nans
No ratings yet
RHS333 Red Hat Enterprise Security
100% (1)
RHS333 Red Hat Enterprise Security
6 pages
Networking Worksheet: Ironport Email Security Appliance Technical Support: 1-877-641-Iron (4766)
No ratings yet
Networking Worksheet: Ironport Email Security Appliance Technical Support: 1-877-641-Iron (4766)
2 pages
Pts000108 Dicom Conformance Statement Mylab f11xx 01.3 04
No ratings yet
Pts000108 Dicom Conformance Statement Mylab f11xx 01.3 04
118 pages
Cisco Expressway Authenticating Accounts Using LDAP Deployment Guide X8 5
No ratings yet
Cisco Expressway Authenticating Accounts Using LDAP Deployment Guide X8 5
19 pages
RHCSA Solved Paper
0% (1)
RHCSA Solved Paper
5 pages
OSS 2marks With Answer
100% (3)
OSS 2marks With Answer
39 pages
OpenLDAP Admin Guide PDF
No ratings yet
OpenLDAP Admin Guide PDF
270 pages
Siebel Configuration Questions and Answers
No ratings yet
Siebel Configuration Questions and Answers
24 pages
SAP Cloud Platform Integration Onboarding Guide
100% (3)
SAP Cloud Platform Integration Onboarding Guide
44 pages
Added Content
No ratings yet
Added Content
8 pages
Linux Server-Client and OpenLDAP
No ratings yet
Linux Server-Client and OpenLDAP
5 pages
Enterprise AD Services v1.9 1
No ratings yet
Enterprise AD Services v1.9 1
16 pages
Bizhub C550 Install Guide
No ratings yet
Bizhub C550 Install Guide
13 pages
BOS85T10
No ratings yet
BOS85T10
235 pages
iR1750iF 5 SYSTEM en Us PDF
No ratings yet
iR1750iF 5 SYSTEM en Us PDF
320 pages
Enabling OID - SSO For E-Busi...
No ratings yet
Enabling OID - SSO For E-Busi...
12 pages
PHPMaker
100% (1)
PHPMaker
47 pages
Documentation - Zabbix Documentation 6.4.en
No ratings yet
Documentation - Zabbix Documentation 6.4.en
773 pages
FortiMail Cookbook
No ratings yet
FortiMail Cookbook
140 pages
Release Note CLX-92x1 Series V6.P6.03.EC1512.10
No ratings yet
Release Note CLX-92x1 Series V6.P6.03.EC1512.10
7 pages
Vcloud Director Administrator's Guide
No ratings yet
Vcloud Director Administrator's Guide
258 pages
LDAP Integration Feature Module
No ratings yet
LDAP Integration Feature Module
20 pages
TRITON Unified Security Center Help, Version 7.7
No ratings yet
TRITON Unified Security Center Help, Version 7.7
46 pages
RACF V1.10 Command Syntax Booklet
No ratings yet
RACF V1.10 Command Syntax Booklet
68 pages
How Do I Configure Active Directory Integration With The DC Agent On My Barracuda Web Filter
No ratings yet
How Do I Configure Active Directory Integration With The DC Agent On My Barracuda Web Filter
8 pages
Oblix Schema Description
No ratings yet
Oblix Schema Description
61 pages
Siebel TSiebel Tools Configuration Interview Questions - Docxools Configuration Interview Questions
No ratings yet
Siebel TSiebel Tools Configuration Interview Questions - Docxools Configuration Interview Questions
52 pages
Dnsmasq
No ratings yet
Dnsmasq
10 pages
How To Configure Samba As A Primary Domain Controller
No ratings yet
How To Configure Samba As A Primary Domain Controller
150 pages
Fortios v7.2.4 Release Notes
No ratings yet
Fortios v7.2.4 Release Notes
66 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.