EX362 Video Prep

This page contains the necessary resources to help you prepare for the Red Hat Certified Specialist in Identity Management exam, EX362. This follows loosely the youtube playlist as much as possible with various examples and ideas. At the bottom, you will also find our own example practice exam for you to try your hand at to test your knowledge.

The list of objectives can be found here. Note that the exam objectives can change at any time. It is the responsibility of the reader to always review the objectives prior to studying and taking the exam to ensure success.

Note
Please note that we are not affiliated with Red Hat. The materials and examples used are our own and do not reflect the training programs provided by Red Hat and are educational only. We do not disclose any of the tasks, questions, or material on the exam as it would violate the NDA. Any questions sent to us about anything directly related to the exam will not be answered. We also do not provide any one-on-one tutoring or online teaching courses.
If exam objectives have changed to where the videos and this material are missing information, we can add on at any time upon request. If there are things about FreeIPA that you’d like to see in the videos that may fit into objective, we can add it also upon request.

Overview

The video series goes over setting up FreeIPA in a lab/VM environment by following the objectives as outlined by Red Hat. The list of objectives can be found here.

Exam Information

The EX362 exam tests your knowledge in a real world format style test - Meaning just like any Red Hat exam, it is performance-based and you perform tasks as if you were on the job. You are evaluated on the tasks you perform and if they meet the objective criteria. The EX362 is related to FreeIPA or Red Hat Identity Management and counts toward the RHCA (Red Hat Certified Architect).

To take the exam, you must have at least an RHCSA. If you are attempting to become a Red Hat Certified Architect, you must have an RHCE.

Hardware Recommendations

The minimum requirements for IdM are fairly low. 2GB of RAM, 1 core, and a 10GB disk. However, we believe that’s too low, especially if we plan on scaling out. And during upgrades, you would need at least 4GB of RAM for the operations to be successful. Below are our minimum recommendations:

  • 2 (virtual) CPU Core
  • 4 GB of RAM
  • 10GB+ disk or partition for /var/lib/dirsrv

Per the Red Hat documentation, consider that with at least 10k users and 100 groups, you would need at least 3GB of RAM and 1GB swap. If you end up having 100k users and 50k groups, then 16GB of RAM and 4GB of swap is recommended. In fact, in larger deployments, it’s more effective to increase RAM than disk, as most data is stored in cache.

View the resources above for directory server tuning information.

Installing FreeIPA/Red Hat IdM with replicas for growth and scale

Server Name IP Address
idm1.example.com 192.168.15.2
idm2.example.com 192.168.15.3
Note
IPA Servers should either have a DHCP reservation or a static address. In the even that you have either, DNS should always be pointing at 127.0.0.1, especially if your replica serves DNS. Both of our replicas serve DNS, so loopback is sufficient for our name server.
In later versions of FreeIPA, there is support to force network manager to ensure resolv.conf is loopback without the need to set it by hand with nmcli.
# Set a static address - It's important for your IdM servers
# to have static addresses or a DHCP reservation.
% nmcli con mod eth0 ipv4.address 192.168.15.2/24
% nmcli con mod eth0 ipv4.gateway 192.168.15.1
% nmcli con mod eth0 ipv4.method manual
% nmcli con mod eth0 ipv4.dns-search example.com

# You should set this if your replica serves DNS! If not, set it to
# one or more of your IdM replicas that do.
% nmcli con mod eth0 ipv4.dns 127.0.0.1
% nmcli con up eth0
# Examples of using ipa-server-install
# RHEL 7
% yum install ipa-server ipa-server-dns ipa-server-trust-ad
# RHEL 8
% yum module enable idm:DL1/{server,dns,adtrust,client,common}
% yum install ipa-server ipa-server-dns ipa-server-trust-ad
% ipa-server-install
% ipa-server-install --domain example.com --realm EXAMPLE.COM \
    --reverse-zone=15.168.192.in-addr.arpa. \
    --no-forwarders \
    --no-ntp \
    -p Passw0rd! \
    -a Passw0rd!
Note
Zone Overlap

In the video demo, you may have noticed I had to use an extra switch, –allow-zone-overlap. This may be needed if your lab or systems either have direct connectivity to the internet or you don’t have a DNS server already with usable A records. Especially in this case, we are using the ‘example.com’ domain which is not owned by us. In a real world scenario, you wouldn’t use –allow-zone-overlap, because you shouldn’t be domain hijacking. For the sake of your lab (or my demo), you may need it depending on your setup.

See the FreeIPA DNS page for more information.

% kinit admin
# We need to make sure that any A records get a corresponding PTR record
% ipa dnsconfig-mod --allow-sync-ptr=True
# Adding a replica
% ipa-replica-install --setup-dns \
    --setup-ca \
    --no-forwarders

# Adding a replica unattended without forwarders
% ipa-client-install --realm EXAMPLE.COM
% kinit admin
% ipa hostgroup-add-member --hosts=ipa02.example.com ipaservers
% ipa-replica-install --setup-dns \
    --setup-ca \
    --no-forwarders \
    --unattended

Creating Users, Groups, and Policies

Users Login Name Type Group Role
John Smith jsmith Normal admins  
Bob Rufus brufus Normal corp  
Larry Dufus ldufus Normal helpdesk  
SysHost Management syshostmgt Normal   Host Manager
Robert Cole rcole Staged    
Thomas Snyder tsnyder Preserved    
Groups Policy
HelpDesk helpdesk
corp  
enrollers Enrollment Administrator
Roles Privilege
Host Manager Host administrators
  Host group administrators
  Netgroups administrators
  Host enrollment

Install and configure IdM Clients

Client Name IP Address
client.example.com 192.168.15.10
nfs.example.com 192.168.15.11
Note
Depending on your architecture and setup, IdM clients should either be pointing directly at the IdM servers for DNS (at least two of them) or pointing at the DNS server in the environment that is delegating that domain to the IdM domain controllers.
In our lab, our IdM servers are our only DNS servers, thus it makes sense that our clients should point to them. In that scenario, you would configure your DHCP server to use the IdM servers as the name servers and/or configure them in a static manner depending on your environment.
# If your client is not pointing at the IdM DNS and you
# don't have another DNS server that's performing delegation,
# change your name servers.
% nmcli con mod eth0 ipv4.dns 192.168.15.2
% nmcli con mod eth0 +ipv4.dns 192.168.15.3
% nmcli con mod eth0 ipv4.dns-search example.com

# Optionally, if your clients don't have DHCP
# reservations, set a static address.
% nmcli con mod eth0 ipv4.address 192.168.15.10/24
% nmcli con mod eth0 ipv4.gateway 192.168.15.1
% nmcli con mod eth0 ipv4.method manual

# It might be a good idea to set your hostname if you haven't already
% hostnamectl set-hostname client.example.com
% hostname client.example.com

# Install the ipa-client packages
% yum install ipa-client -y
% ipa-client-install --realm EXAMPLE.COM --domain example.com
. . .
% id admin
uid=686600000(admin) gid=686600000(admins) groups=686600000(admins)

Create a trust with Active Directory

Server Name IP Address
ad.example.net 192.168.15.12

Back up an IdM infrastructure

There are multiple ways you can backup IPA.

  • Full backup: Default, shuts down IPA before performing a backup. This backs up with raw files. As such, it must be done offline.
  • Data bacup: Backs up a copy of the ldap data and the changelog (the IPA-REALM instance, DogTag, IPA backend). This can be done online.
# Turns off IPA completely and perform a backup
% ipa-backup
# Backs up data only and doesn't take down IPA
% ipa-backup --data --online
# Backs up data only and gpg encrypts
% ipa-backup --gpg --gpg-keyring=/root/keys --data --online

To restore a backup, the ipa-restore command is available.

% ipa-restore /var/lib/ipa/backup/

Configure IdM as an LDAP backend for external services

Most services and applications that authenticate users do typically have LDAP support. IdM can be used as an LDAP backend. You typically need only a few things to authenticate users from IdM to an application.

  • Base DN, this always ends up being the top level of your domain: dc=example,dc=com - All accounts share this common base.
  • Bind DN, this is a system account that binds to the directory to assist with searches and authentication
  • Attribute mappings
  • Groups, depending on the application

Below is a table of common DN’s you may specify in an application:

DN’s Path Filter (if applicable)
Base DN dc=example,dc=com  
User DN cn=users,cn=accounts,dc=example,dc=com uid=…
Group DN cn=groups,cn=accounts,dc=example,dc=com (objectClass=groupOfNames)
Bind DN uid=account,cn=sysaccounts,cn=etc,dc=example,dc=com  
% ipa user-show admin --all | grep '^dn'
  dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com

Below is a table of common attributes that may be used to map user information in the application.

Type Attribute
Login Name uid
First Name givenName
Surname sn
Email mail
Groups memberOf
Full Name cn

Below are two ways to create a bind account (bind DN). The first way is the LDAP way. The second way is the ipa-ldap-updater.

% kinit admin
% ldapadd -Y GSSAPI
. . .
dn: uid=binder,cn=sysaccounts,cn=etc,dc=example,dc=com
objectclass: account
objectclass: simplesecurityobject
uid: binder
userPassword: password123
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
# Press CTRL+d
adding new entry "uid=binder,cn=sysaccounts,cn=etc,dc=example,dc=com"
% kinit admin
% cat << EOF > binder.update
dn: uid=binder,cn=sysaccounts,cn=etc,dc=example,dc=com
add:objectclass:account
add:objectclass:simplesecurityobject
add:uid:binder
add:userPassword:password123
add:passwordExpirationTime:20380119031407Z
add:nsIdleTimeout:0
EOF
% ipa-ldap-updater binder.update

When this account is created, you can then specify the full DN for that object into a bind DN field, along with it’s password into an accompanying bind password field.

If you’d like an example of setting up Ansible Tower (or AWX, the open source version of tower) against IdM, you can click here.

Kerberos

On some applications, it is possible to use kerberos authentication rather than a straight bind account. The general idea is the same when picking out the base dn, attributes, and the like. However, instead you would create an account with an accompanying LDAP/… service principal to do the authentication.