EX362 Exam Prep

Original author: nazunalika

Last modified: Wed Dec 23 00:26

This page contains the necessary resources to help you prepare for the Red Hat Certified Specialist in Identity Management exam, EX362. This follows the youtube playlist as much as possible with various examples and ideas. Soon to come, 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

Affiliation and Exam Information

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 exam objectives have not changed but operational tasks have, we will note them as we find them. 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. However, it is likely those extra things would be better suited in the separate FreeIPA section on this site.

Contents

Overview
Exam Information
Resources
Hardware Recommendations
IdM Server Installation and Configuration
IdM Client Installation and Configuration
- Install and configure IdM Clients
- Configure Kerberized services
IdM HA Configuration
- Configure and manage a certificate authority
- Create Secret Vaults
IdM Users and Policies Management
Creating Trust with AD Domain
- Create trust relationships with Active Directory
- Authenticate users with an Active Directory domain
IdM maintenance
- Back up an IdM infrastructure
- Perform a backup without interruption of services
Value Add
- Use the REST api to query IdM
- Implement an IdP

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.

Resources

FreeIPA
Red Hat Documentation
Trust Anatomy/SSSD Troubleshooting
Directory Server Tuning
FreeIPA Workshop
FreeIPA Workshop Curriculum
Our Page

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 in the previous section for directory server tuning information.

IdM Server Installation and Configuration

Install IdM in a scalable, fault tolerant environment

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 event 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 and recommended 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 8
% yum module enable idm:DL1/{server,dns,adtrust,client,common}
% yum install ipa-server ipa-server-dns ipa-server-trust-ad
# RHEL 9
% yum install ipa-server ipa-server-dns ipa-client sssd sssd-ipa
# Installation, interactive, does not setup specific components
% ipa-server-install

# Installation, mostly automatic (recommended)
# This will setup DNS and the necessary pieces for an AD trust
# Optionally, you can use the --netbios-name switch to set your forest netbios name
% ipa-server-install --domain example.com --realm EXAMPLE.COM \
    --reverse-zone=15.168.192.in-addr.arpa. \
    --no-forwarders \
    --no-ntp \
    --setup-dns \
    --setup-adtrust \
    -p Passw0rd! \
    -a Passw0rd!

# Configure the firewall for RHEL 7
% firewall-cmd --permanent --add-service={ntp,http,https,freeipa-ldap,freeipa-ldaps,kerberos,freeipa-replication,kpasswd,dns}
# RHEL 8
% firewall-cmd --permanent --add-service={freeipa-4,ntp,dns}

% kinit admin
# We need to make sure that any A records get a corresponding PTR record, otherwise you're making them manually.
% 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	UID/GID
John Smith	jsmith	Normal	admins		Auto
Bob Rufus	brufus	Normal	corp		Auto
Larry Dufus	ldufus	Normal	helpdesk		Auto
Robert Cole	rcole	Staged			Auto
Thomas Snyder	tsnyder	Preserved			Auto
SysHost Management	syshostmgt	Normal		Host Manager	10000

Groups	Policy
HelpDesk	helpdesk
corp
enrollers	Enrollment Administrator

Roles	Privilege
Host Manager	Host administrators
	Host group administrators
	Netgroups administrators
	Host enrollment

Note

Custom UID/GID

It is possible to create the users with a custom uid/gid with the switches --uid and --gidnumber which you will see below. It is also possible to set random passwords with --random.

See ipa user-add --help for more switches.

Note

Password Expiration

When you make a user with the --password switch or use ipa passwd to set a password, it is automatically expired and must be changed on next login. If you want to avoid this from happening, you will need to set a random password via --password or --random, and then use kpasswd username to change it to the desired password. This does not make the account non-expiring.

# Creating users with a password, create all the accounts from the table (except from syshost)
% ipa user-add --first="John" --last="Smith" --password jsmith

# Create the system account with a password of Sup3R$ecre7! and a UID of 10000
% ipa user-add --first="SysHost" --last="Management" --uid=10000 --gidnumber=10000 --password syshostmgt

# Stage a user
% ipa stageuser-add --first="Robert" --last="Cole" rcole

# Preserve a user
% ipa user-del tsynder --preserve

# Create a regular (POSIX) group
% ipa group-add corp

# Create a member only group
% ipa group-add --nonposix HelpDesk
% ipa group-add --nonposix enrollers

# Add the HelpDesk group to the helpdesk policy
# Add the enrollers group to the Enrollment Administrator role
% ipa role-add-member "helpdesk" --groups=HelpDesk
% ipa role-add-member "Enrollment Administrator" --groups=enrollers

# Create a role with privileges
% ipa role-add "Host Manager"
% ipa role-add-privilege "Host Manager" \
    --privileges="Host administrators" \
    --privileges="Host group administrators" \
    --privileges="Netgroups administrators" \
    --privileges="Host enrollment"

# Add the syshostmgt user as a member of the role
% ipa role-add-member "Host Manager" --users="syshostmgt"

# Set our user passwords to CentOS123!$ so that way we don't have to change them later
% kpasswd jsmith

# If we already set the password we want but we don't want it to expire without making a policy or prompt for a password change (NOT RECOMMENDED)
% ldapmodify -x -w 'Passw0rd!' -D 'cn=Directory Manager'
dn: uid=syshostmgt,cn=users,cn=accounts,dc=example,dc=com
changetype: modify
delete: krbLastPwdChange

(Press CTRL+D)

New Passwords Expired

The common question we receive (and even the #freeipa IRC receive) is "Why can't we just set the password to not be expired right away?" See this page for information on why this is. You may also look at the pagure page and the Red Hat bugzilla related bug.

Implement a SSO

To setup a very, very simple SSO, you can setup a simple location that requires a login.

% ipa-getkeytab -s idm1.example.com -p http/http.example.com -k /etc/httpd/conf/http.keytab
% vi /etc/httpd/conf.d/location.conf
&lt;Location "/"&gt;
  AuthType Kerberos
  AuthName "IPA Kerberos Auth"
  # Keytab
  Krb5Keytab /etc/httpd/conf/http.keytab
  # Kerb settings
  KrbMethodNegotiate on
  KrbMethodK5Passwd on
  KrbServiceName HTTP
  KrbAuthRealms EXAMPLE.COM
  KrbSaveCredentials off
  Require valid-user
&lt;/Location&gt;

IdM Client Installation and Configuration

Install and configure IdM Clients

Client Name	IP Address
client.example.com	192.168.15.10
nfs.example.com	192.168.15.11
utility.example.com	192.168.15.12

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)

Configure Kerberized services

One of the things that you may end up doing, whether by hand or in an automated fashion, is creating kerberized services. In a previous section, we addressed creating an NFS service for both a server and a client for the purpose of automating home directory mounts on a client when a user logs in. So you already have the idea of what this entails.

# Create kerberos service
% ipa service-add HTTP/http.example.com

Not only that, it's probably a good idea to actually get the keytab.

% kinit admin
% ipa-getkeytab -s idm1.example.com -p HTTP/http.example.com -k /etc/krb5.keytab

For an example of automating keytab creation and retrieval, see the CentOS/FreeIPA page on this site.

IdM HA Configuration

Configure and manage a certificate authority

By default FreeIPA stands up its own CA. And because of this, this allows you or your workplace to be able to issue certificates, that can be used in a wide variety of services, the most common or obvious one would be for Apache httpd.

There's a couple of ways you can get a certificate signed by FreeIPA. One method is to generate your own CSR and request it to be signed by FreeIPA. Another way is you can do it all from one command, ipa-getcert, and optionally, either have the certificate in PEM format or an NSS database. We'll address these examples.

# Creating an SSL certificate in the PEM format
% ipa service-add HTTP/http.example.com
% ipa-getcert request -f /etc/pki/tls/certs/http.pem -k /etc/pki/tls/private/http.key -K HTTP/http.example.com -D http.example.com
New signing request "20190902000318" added.
# Verify
% ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20190902000318':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/http.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/http.pem'
        CA: IPA
        issuer: CN=Certificate Authority,O=EXAMPLE.COM
        subject: CN=http.example.com,O=EXAMPLE.COM
        expires: 2021-09-02 00:03:19 UTC
        dns: http.example.com
        principal name: HTTP/http.example.com@EXAMPLE.COM
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

# Create an SSL certificate in the NSS format
% ipa-getcert request -d /etc/pki/tls/certs/nss -n 'Test' -K HTTP/http.example.com -D http.example.com
New signing request "20190902000756" added.
# Verify
% ipa-getcert list
. . .
Request ID '20190902000756':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/tls/certs/nss',nickname='Test',token='NSS Certificate DB'
        certificate: type=NSSDB,location='/etc/pki/tls/certs/nss',nickname='Test',token='NSS Certificate DB'
        CA: IPA
        issuer: CN=Certificate Authority,O=EXAMPLE.COM
        subject: CN=http.example.com,O=EXAMPLE.COM
        expires: 2021-09-02 00:07:57 UTC
        dns: http.example.com
        principal name: HTTP/http.example.com@EXAMPLE.COM
        key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

By default, when a certificate request is performed (and succeeds to be signed by the IPA CA), it is typically tracked and auto-renewed by default. This is done by the certmonger service, which eliminates the need to have to renew anything by hand.

Create Secret Vaults

When a domain supports the KRA role, it can hold password vaults or anything that's considered "secret". You can add the KRA role by simply running on each relevant domain controller:

` % ipa-kra-install `

(more to come)

IdM Users and Policies Management

In FreeIPA, there are two sets of policies:

Role Based Access Control (RBAC) which are the permissions, delegated or otherwise, that allow (or deny) access to various pieces of FreeIPA. This can be users that have the ability to reset passwords, modify groups, or perhaps they can issue keytabs. This was partially covered in a previous section.
Host Based Access Control (HBAC) which are the permissions granted to a user or users to access systems on various (PAM) services, such as ssh or logging into a desktop system (eg, GDM).

Configure Policies and User Access

HBAC, or Host Based Access Controls, are permissions that grant user or users access to systems via any number of services. The services are PAM services. No doubt you have looked in /etc/pam.d before and have seen quite a few files or even modified them by hand at some point.

% ls -l /etc/pam.d/
total 80
-rw-r--r--. 1 root root 272 May 11  2019 atd
-rw-r--r--. 1 root root 232 Apr 15 15:28 config-util
-rw-r--r--. 1 root root 328 Nov  8  2019 crond
lrwxrwxrwx. 1 root root  32 Jan 14  2020 fingerprint-auth -> /etc/authselect/fingerprint-auth
-rw-r--r--. 1 root root  70 Apr 24 06:35 ksu
-rw-r--r--. 1 root root 715 Apr 24 05:38 login
-rw-r--r--. 1 root root 154 Apr 15 15:28 other
-rw-r--r--. 1 root root 168 Apr  6 20:08 passwd
lrwxrwxrwx. 1 root root  29 Jan 14  2020 password-auth -> /etc/authselect/password-auth
-rw-r--r--. 1 root root 155 Apr  8 22:00 polkit-1
lrwxrwxrwx. 1 root root  25 Jan 14  2020 postlogin -> /etc/authselect/postlogin
-rw-r--r--. 1 root root 640 Apr 24 05:38 remote
-rw-r--r--. 1 root root 143 Apr 24 05:38 runuser
-rw-r--r--. 1 root root 138 Apr 24 05:38 runuser-l
lrwxrwxrwx. 1 root root  30 Jan 14  2020 smartcard-auth -> /etc/authselect/smartcard-auth
lrwxrwxrwx. 1 root root  25 Jun 15 10:18 smtp -> /etc/alternatives/mta-pam
-rw-r--r--. 1 root root  76 Apr  6 20:11 smtp.postfix
-rw-r--r--. 1 root root 727 Feb  4  2020 sshd
-rw-r--r--. 1 root root 214 Apr 23 20:48 sssd-shadowutils
-rw-r--r--. 1 root root 566 Apr 24 05:38 su
-rw-r--r--. 1 root root 154 Apr 23 19:40 sudo
-rw-r--r--. 1 root root 178 Apr 23 19:40 sudo-i
-rw-r--r--. 1 root root 137 Apr 24 05:38 su-l
lrwxrwxrwx. 1 root root  27 Jan 14  2020 system-auth -> /etc/authselect/system-auth
-rw-r--r--. 1 root root 248 Jul 21 07:57 systemd-user
-rw-r--r--. 1 root root  84 May 11  2019 vlock

On a typical Red Hat system, the most common ones (such as su, sshd, sudo) imports the system-auth file, so the login request is processed through those means. When defining HBAC rules, you either must allow "all" services or be selective. For example, if an HBAC rule allows "sshd", a user is allowed to ssh into a system, but wouldn't allow them to login locally, as that goes through login. If you want the user to be able to run the su and sudo commands, you would also need to allow those services. Otherwise, the user is denied, despite sudo policies being available.

[label@mgt ~]$ sudo -i
[sudo] password for label:
sudo: PAM account management error: Permission denied

In FreeIPA, there is typically a rule already predefined that allows everyone to access all systems and all services. This can be removed or disabled and this removes host access to everything immediately. This is typically recommended in most environments where there are security standards and procedures in place.

# To disable
% ipa hbacrule-disable allow_all
# To delete instead
% ipa hbacrule-del allow_all

When performing a FreeIPA installation, it is possible to add --no-hbac-allow that will disable the allow_all rule.

Below are some examples of adding access.

# Allow all admins to access all systems
% ipa hbacrule-add --hostcat=all --servicecat=all --desc='Allow all admins to access all systems' All_Admins
% ipa hbacrule-add-user --groups=admins All_Admins

# And then test...
% ipa hbactest --rules=All_Admins --user=jsmith --host=client.example.com --service=login

# Allow the corp users to access the client system only using the sshd pam services
% ipa hbacrule-add --desc='Allow corp users to access client on ssh' corp_access
% ipa hbacrule-add-user --groups=corp corp_access
% ipa hbacrule-add-host --hosts=client.example.com corp_access
% ipa hbacrule-add-service --hbacsvcs=sshd corp_access

# And then test...
% ipa hbactest --rules=corp_access --user=brufus --host=client.example.com --service=sshd

Configure roaming/automounted home directories

You will need to configure your NFS server to serve up roaming home directories for users and then your client should have automouting enabled.

Note

Client Kerberos Service

It may not be required to create an nfs kerberos service for the client. The ipa-client-automount command may already handle this but it does not hurt to create one. In fact, the host keytab is used on the client side anyway. Creating an NFS client keytab may have been required back in the EL6 days.

# IDM Steps
% kinit admin
% ipa service-add nfs/nfs.example.com
% ipa service-add nfs/client.example.com

# Setup the automounting locations
% ipa automountmap-add default auto.home
% ipa automountkey-add default --key "/home" --info auto.home auto.master
% ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=krb5,soft nfs.example.com:/exports/home/&" auto.home

# NFS Server Steps
% yum install nfs-utils -y
% mkdir /exports/home
% vi /etc/exports
/exports/home *(rw,sec=sys:krb5:krb5i:krb5p)

# Make the home directories for all users and move them to /export/home
% mkhomedir_helper jsmith
% mv /home/jsmith /export/home/

# Create the necessary keytabs
% kinit admin
% ipa-getkeytab -s idm1.example.com -p nfs/nfs.example.com -k /etc/krb5.keytab

# Verify keytab
% klist -ket /etc/krb5.keytab

# Enable and start nfs
% systemctl enable nfs-server --now

# Open the necessary firewall ports
% firewall-cmd --add-service=nfs --permanent
% firewall-cmd --complete-reload

# Client steps
% kinit admin
% ipa-getkeytab -s idm1.example.com -p nfs/client.example.com -k /etc/krb5.keytab
% ipa-client-automount --location=default

# Verify keytab
% klist -ket /etc/krb5.keytab

To test, login to the system via ssh or console and verify the home directory has mounted. /var/log/messages and secure will display errors in case of failure.

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.

Note

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.

Creating Trust with AD Domain

Create trust relationships with Active Directory

Note

AD Setup

We do not cover setting up an AD forest here. This is out of scope for this series. If you are using Server 2016 or higher and you are using "core", look up the commands:

Install-WindowsFeature AD-domain-services Import-Module ADDSDeployment Install-ADDSForest

Server Name	IP Address
ad.example.net	192.168.15.15

For our trust, the AD server will need to be configured to be the example.net domain with the hostname of ad.example.net. This way, we are not colliding in DNS and both AD and IdM should be able to communicate with each other as two separate forests. It is recommended to use Windows Server 2016 (with the same domain functional level) for this setup, as experience with that product is a recommended prerequisite for the exam.

% yum install ipa-server-trust-ad -y
% firewall-cmd --add-service=freeipa-trust --permanent
success
% firewall-cmd --reload
success
% ipa-adtrust-install
. . .
# This is the admin@REALM IPA account
admin password:

WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing samba configuration.

# Type 'yes' here
Do you wish to continue? [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.

# You can press enter here to accept the default. If you have BSD, Solaris, Omnios, HP-UX, AIX, or RHEL 5 and older clients
# you may want to enable this. Some apps may benefit from this also.
Enable trusted domains support in slapi-nis? [no]:

Enter the NetBIOS name for the IPA domain.
Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
Example: EXAMPLE.

# You can accept the default or put your own.
NetBIOS domain name [IPA]: IPA0

WARNING: 4 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.

# You should always say yes.
Do you want to run the ipa-sidgen task? [no]: yes

. . .

# This will complete and list ports to open and such. We did this earlier.

Now that the AD trust components are prepped, depending on the setup, we'll need to do some DNS zone forwards. It is likely you have IPA and AD running their own DNS. Note: This may not be the case in a real world scenario.

# We need to create a forward zone here for the example.net zone
% ipa dnsforwardzone-add example.net --forwarder=192.168.15.15 --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: 192.168.15.15
  Forward policy: only

# We should probably create a few dns records...
# Assuming the AD netbios name is EXAMPLEAD, use the syntax hostname.NETBIOS here
% ipa dnsrecord-add example.com ad.EXAMPLEAD --a-ip-address=192.168.15.15
# Same idea here, but we're only doing the netbios name and saying the name server record is the AD server
% ipa dnsrecord-add example.com EXAMPLEAD --ns-hostname=ad.EXAMPLEAD

# We need to allow the zones to be transferable to the AD domain
% ipa dnszone-mod example.com --allow-transfer=192.168.15.15

On the AD side, we need to create the IPA zone. It's absolutely required.

C:\Windows\System32>dnscmd 127.0.0.1 /ZoneAdd example.com /Secondary 192.168.15.2

You should probably double check that the DNS records are returning on the IDM servers.

% dig _ldap._tcp.example.com SRV
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> SRV _ldap._tcp.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14793
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.example.com.      IN      SRV

;; ANSWER SECTION:
_ldap._tcp.example.com. 86400 IN      SRV     0 100 389 idm1.example.com.
_ldap._tcp.example.com. 86400 IN      SRV     0 100 389 idm2.example.com.

;; AUTHORITY SECTION:
example.com.          86400   IN      NS      idm1.example.com.
example.com.          86400   IN      NS      idm2.example.com.

;; ADDITIONAL SECTION:
idm1.example.com.      1200    IN      A       192.168.15.2
idm2.example.com.      1200    IN      A       192.168.15.3

# Same with the AD records
% dig _ldap._tcp.example.net SRV
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> SRV _ldap._tcp.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12195
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.example.net.       IN      SRV

;; ANSWER SECTION:
_ldap._tcp.example.net. 600    IN      SRV     0 100 389 ad.example.net.

. . .

Now that they are returning, intiate the trust.

% ipa trust-add --type=ad example.net --admin Administrator --password
Active Directiron domain administrator's password: (type password here)
-----------------------------------------------------
Added Active Directory trust for realm "example.net"
-----------------------------------------------------
  Realm name: example.net
  Domain NetBIOS name: EXAMPLEAD
  Domain Security Identifier: S-1-5-21-XXXXXXXXXX-YYYYYYYYY-ZZZZZZZZZZ
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified

# Check that an AD user is resolvable. You can do this with DOMAIN\name or name@DOMAIN
% id EXAMPLEAD\\administrator
% id administrator@example.net

Authenticate users with an Active Directory domain

As we disabled the allow_all rule, let's create a set of groups first and then the HBAC rule.

# Create the starting AD group
% ipa group-add adusers
# Create an external group. This is required for AD users.
% ipa group-add --external adgroup_external
# Add an AD user into the external group
% ipa group-add-member --users=administrator@example.net adgroup_external
# Make the external group a member of ad users
% ipa group-add-member --groups=adgroup_external adusers

As we've made an HBAC rule before, this should be simple.

% ipa hbacrule-add --hostcat=all --servicecat=all --desc='ad users all access' adusers_access
% ipa hbacrule-add-user --groups=adusers adusers_access
% ipa hbactest --rules=adusers_access --user=administrator@example.net --host=client.example.com --service=sshd

The test should pass without any issues.

Note

Group Types

While this may not be required information while working on the exam, it's important to understand that there are different group types in AD and the behavior changes based on the group type.

Groups in Active Directory have three types. These three types can actually change the behavior of how SSSD on the IPA domain controllers resolve them or if they'll even be resolvable at all. The three types are 'Domain Local', 'Global', and 'Universal'. If at all possible, avoid groups being 'Global'. Domain Local or Universal is recommended.

IdM maintenance

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 backup: 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 and gpg encrypts
% ipa-backup --gpg --gpg-keyring=/root/keys

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

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

Perform a backup without interruption of services

The backup command allows you to pass an online flag to ensure a backup taken doesn't down the IPA services. Note that not everything can be backed up online.

# 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

Value Add

Use the REST api to query IdM

When you invoke the ipa command, you are actually communicating with the API that runs on the IdM replicas. Operations done are sent via a POST with JSON data. The return data is also in JSON and translated to be readable in the terminal. Because it's JSON, custom scripts can be made with say perl or python that communicates with the API to send the calls, perhaps for specific tasks, jobs, or other operations that could be automated. You can also use curl to do this also if you so choose.

The question becomes, "well, how do I know the right data to send?" You can issue the -vv switch to see the request being sent.

% ipa -vv ping
ipa: INFO: trying https://idm1.example.com/ipa/json
ipa: INFO: [try 1]: Forwarding 'schema' to json server 'https://idm1.example.com/ipa/json'
ipa: INFO: trying https://idm1.example.com/ipa/session/json
ipa: INFO: [try 1]: Forwarding 'ping/1' to json server 'https://idm1.example.com/ipa/session/json'
ipa: INFO: Request: {
    "id": 0,
    "method": "ping/1",
    "params": [
        [],
        {
            "version": "2.230"
        }
    ]
}
ipa: INFO: Response: {
    "error": null,
    "id": 0,
    "principal": "admin@EXAMPLE.COM",
    "result": {
        "summary": "IPA server version 4.6.4. API version 2.230"
    },
    "version": "4.6.4"
}
-------------------------------------------
IPA server version 4.6.4. API version 2.230
-------------------------------------------

If you look at the 'request' section, you can see the data that is sent. Each request has a method and params, where method is a command to be excuted and params is simply an array that contains positional arguments and a dictionary of options. If you take a look at say, group-show, you would see a different request.

% ipa -vv group-show admins
ipa: INFO: trying https://idm1.example.com/ipa/session/json
ipa: INFO: [try 1]: Forwarding 'group_show/1' to json server 'https://idm1.example.com/ipa/session/json'
ipa: INFO: Request: {
    "id": 0,
    "method": "group_show/1",
    "params": [
        [
            "admins"
        ],
        {
            "version": "2.230"
        }
    ]
}
### Lots of output ###

Let's say I wanted to perform that in a simple bash script that uses curl. I would perform a kinit and then run the script below to have it login for me via kerberos and do the work.

#!/bin/bash
ipaReplica=idm1.example.com
cookieJar=my.cookie.jar

# Login with Kerberos
curl -v \
  -H referer:https://$ipaReplica/ipa \
  -c $cookieJar -b $cookieJar \
  --cacert /etc/ipa/ca.crt \
  --negotiate -u : \
  -X POST \
  https://$ipaReplica/ipa/session/login_kerberos

# Send user_find method request
curl -v \
  -H referer:https://$ipaReplica/ipa \
  -H "Content-Type:application/json" \
  -H "Accept:applicaton/json"\
  -c $cookieJar -b $cookieJar \
  --cacert /etc/ipa/ca.crt \
  -d  '{"method":"group_show/1","params":[["admins"],{}],"id":0}' \
  -X POST \
  https://$ipaReplica/ipa/session/json

Any of the commands ran via ipa can be reviewed with the -vv switch so you can see what kind of call it's making and how it's making it. Thus, making it easier to tie into your own scripts. On the Web UI, you can go to IPA Server -> API Browser to find more information on the specific API calls.

Implement an IdP

While not strictly a certification objective at this present time, there may be a chance it could be. FreeIPA 4.10+ have the ability to implement authentication to external identity providers. FreeIPA allows you to use RADIUS proxy authentication for example, but using this same method, an OAuth 2.0 authorization server could be used as well. When it comes to an IdP, you can instead configure IdP clients using ipa idp-add and use software like Keycloak or otherwise that supports OAuth 2.0 workflows. We recommend checking out the FreeIPA Workshop Unit 12 for more details.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ex362.rst

ex362.rst

EX362 Exam Prep

Overview

Exam Information

Resources

Hardware Recommendations

IdM Server Installation and Configuration

Install IdM in a scalable, fault tolerant environment

Creating Users, Groups, and Policies

New Passwords Expired

Implement a SSO

IdM Client Installation and Configuration

Install and configure IdM Clients

Configure Kerberized services

IdM HA Configuration

Configure and manage a certificate authority

Create Secret Vaults

IdM Users and Policies Management

Configure Policies and User Access

Configure roaming/automounted home directories

Configure IdM as an LDAP backend for external services

Creating Trust with AD Domain

Create trust relationships with Active Directory

Authenticate users with an Active Directory domain

IdM maintenance

Back up an IdM infrastructure

Perform a backup without interruption of services

Value Add

Use the REST api to query IdM

Implement an IdP

Files

ex362.rst

Latest commit

History

ex362.rst

File metadata and controls

EX362 Exam Prep