Configuring and managing Identity Management
Configuring, managing, and maintaining Identity Management in Red Hat Enterprise Linux 8
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your input on our documentation. Please let us know how we could make it better. To do so:
For simple comments on specific passages:
- Make sure you are viewing the documentation in the Multi-page HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document.
- Use your mouse cursor to highlight the part of text that you want to comment on.
- Click the Add Feedback pop-up that appears below the highlighted text.
- Follow the displayed instructions.
For submitting more complex feedback, create a Bugzilla ticket:
- Go to the Bugzilla website.
- As the Component, use Documentation.
- Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
- Click Submit Bug.
Chapter 1. Logging in to Identity Management from the command line
Identity Management (IdM) uses the Kerberos protocol to support single sign-on. Single sign-on means that the user enters the correct user name and password only once, and then accesses IdM services without the system prompting for the credentials again.
In IdM, the System Security Services Daemon (SSSD) automatically obtains a ticket-granting ticket (TGT) for a user after the user successfully logs in to the desktop environment on an IdM client machine with the corresponding Kerberos principal name. This means that after logging in, the user is not required to use the kinit utility to access IdM resources.
If you have cleared your Kerberos credential cache or your Kerberos TGT has expired, you need to request a Kerberos ticket manually to access IdM resources. The following sections present basic user operations when using Kerberos in IdM.
1.1. Using kinit to log in to IdM manually
This procedure describes using the kinit utility to authenticate to an Identity Management (IdM) environment manually. The kinit utility obtains and caches a Kerberos ticket-granting ticket (TGT) on behalf of an IdM user.
Only use this procedure if you have destroyed your initial Kerberos TGT or if it has expired. As an IdM user, when logging onto your local machine you are also automatically logging in to IdM. This means that after logging in, you are not required to use the kinit utility to access IdM resources.
Procedure
To log in to IdM
under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as
example_user
on the local system:[example_user@server ~]$ kinit Password for example_user@EXAMPLE.COM: [example_user@server ~]$
If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:
[example_user@server ~]$ kinit kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
using a Kerberos principal that does not correspond to your local user name, pass the required user name to the
kinit
utility. For example, to log in as theadmin
user:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the
example_user
principal, which means that on this particular host, onlyexample_user
is currently allowed to access IdM services:$ klist Ticket cache: KEYRING:persistent:0:0 Default principal: example_user@EXAMPLE.COM Valid starting Expires Service principal 11/10/2019 08:35:45 11/10/2019 18:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
1.2. Destroying a user’s active Kerberos ticket
This section describes how to clear the credentials cache that contains the user’s active Kerberos ticket.
Procedure
To destroy your Kerberos ticket:
[example_user@server ~]$ kdestroy
Optionally, to check that the Kerberos ticket has been destroyed:
[example_user@server ~]$ klist klist: Credentials cache keyring 'persistent:0:0' not found
1.3. Configuring an external system for Kerberos authentication
This section describes how to configure an external system so that Identity Management (IdM) users can log in to IdM from the external system using their Kerberos credentials.
Enabling Kerberos authentication on external systems is especially useful when your infrastructure includes multiple realms or overlapping domains. It is also useful if the system has not been enrolled into any IdM domain through ipa-client-install
.
To enable Kerberos authentication to IdM from a system that is not a member of the IdM domain, define an IdM-specific Kerberos configuration file on the external system.
Prerequisites
The
krb5-workstation
package is installed on the external system.To find out whether the package is installed, use the following CLI command:
# yum list installed krb5-workstation Installed Packages krb5-workstation.x86_64 1.16.1-19.el8 @BaseOS
Procedure
Copy the
/etc/krb5.conf
file from the IdM server to the external system. For example:# scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
WarningDo not overwrite the existing
krb5.conf
file on the external system.On the external system, set the terminal session to use the copied IdM Kerberos configuration file:
$ export KRB5_CONFIG=/etc/krb5_ipa.conf
The
KRB5_CONFIG
variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.-
Copy the Kerberos configuration snippets from the
/etc/krb5.conf.d/
directory to the external system.
Users on the external system can now use the kinit
utility to authenticate against the IdM server.
Additional resources
-
For details on Kerberos, see the
krb5.conf(5)
,kinit(1)
,klist(1)
, andkdestroy(1)
man pages.
Chapter 2. Viewing, starting and stopping the Identity Management services
Identity Management (IdM) servers are Red Hat Enterprise Linux systems that work as domain controllers (DCs). A number of different services are running on IdM servers, most notably the Directory Server, Certificate Authority (CA), DNS, and Kerberos.
2.1. The IdM services
2.1.1. List of services hosted by IdM servers
Most of the following services are not strictly required to be installed on the IdM server. For example, you can install services such as a certificate authority (CA) or DNS server on an external server outside the IdM domain.
- Kerberos
-
the
krb5kdc
andkadmin
services
IdM uses the Kerberos protocol to support single sign-on. With Kerberos, users only need to present the correct username and password once and can access IdM services without the system prompting for credentials again.
Kerberos is divided into two parts:
-
The
krb5kdc
service is the Kerberos Authentication service and Key Distribution Center (KDC) daemon. -
The
kadmin
service is the Kerberos database administration program.
For information on how to authenticate using Kerberos in IdM, see Logging in to Identity Management from the command line and Logging in to IdM in the Web UI: Using a Kerberos ticket .
- LDAP directory server
-
the
dirsrv
service
The IdM LDAP directory server instance stores all IdM information, such as information related to Kerberos, user accounts, host entries, services, policies, DNS, and others. The LDAP directory server instance is based on the same technology as Red Hat Directory Server. However, it is tuned to IdM-specific tasks.
- Certificate Authority
-
the
pki-tomcatd
service
The integrated certificate authority (CA) is based on the same technology as Red Hat Certificate System. pki
is the Command-Line Interface for accessing Certificate System services.
You can also install the server without the integrated CA if you create and provide all required certificates independently.
For more information, see Planning your CA services.
- Domain Name System (DNS)
-
the
named
service
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. The BIND
(Berkeley Internet Name Domain) implementation of the DNS (Domain Name System) protocols in Red Hat Enterprise Linux includes the named
DNS server. named-pkcs11
is a version of the BIND DNS server built with native support for the PKCS#11 cryptographic standard.
For information, see Planning your DNS services and host names.
- Apache HTTP Server
-
the
httpd
service
The Apache HTTP web server provides the IdM Web UI, and also manages communication between the Certificate Authority and other IdM services.
- Samba / Winbind
-
smb
andwinbind
services
Samba implements the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS) protocol, in Red Hat Enterprise Linux. Via the smb service, the SMB protocol enables you to access resources on a server, such as file shares and shared printers. If you have configured a Trust with an Active Directory (AD) environment, the`Winbind` service manages communication between IdM servers and AD servers.
- One-time password (OTP) authentication
-
the
ipa-otpd
services
One-time passwords (OTP) are passwords that are generated by an authentication token for only one session, as part of two-factor authentication. OTP authentication is implemented in Red Hat Enterprise Linux via the ipa-otpd
service.
For more information, see Logging in to the Identity Management Web UI using one time passwords.
- OpenDNSSEC
-
the
ipa-dnskeysyncd
service
OpenDNSSEC is a DNS manager that automates the process of keeping track of DNS security extensions (DNSSEC) keys and the signing of zones. The ipa-dnskeysyncd
service manages synchronization between the IdM Directory Server and OpenDNSSEC.

2.1.2. List of services hosted by IdM clients
-
System Security Services Daemon: the
sssd
service
The System Security Services Daemon (SSSD) is the client-side application that manages user authentication and caching credentials. Caching enables the local system to continue normal authentication operations if the IdM server becomes unavailable or if the client goes offline.
For more information, see Understanding SSSD and its benefits.
-
Certmonger: the
certmonger
service
The certmonger
service monitors and renews the certificates on the client. It can request new certificates for the services on the system.
For more information, see Obtaining an IdM certificate for a service using certmonger.

2.2. Viewing the status of IdM services
To view the status of the IdM services that are configured on your IdM server, run the ipactl status
command:
[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd 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
The output of the ipactl status
command on your server depends on your IdM configuration. For example, if an IdM deployment does not include a DNS server, the named
service is not present in the list.
You cannot use the IdM web UI to view the status of all the IdM services running on a particular IdM server. Kerberized services running on different servers can be viewed in the Identity
→ Services
tab of the IdM web UI.
You can start or stop the entire server, or an individual service only.
To start, stop, or restart the entire IdM server, see:
To start, stop, or restart an individual IdM service, see:
To display the version of IdM software, see:
2.3. Starting and stopping the entire Identity Management server: the ipactl
utility
Use the ipactl
utility to stop, start, or restart the entire IdM server along with all the installed services. Using the ipactl
utility ensures all services are stopped, started, or restarted in the appropriate order. You do not need to have a valid Kerberos ticket to run the ipactl
commands.
ipactl
commands
To start the entire IdM server:
# ipactl start
To stop the entire IdM server:
# ipactl stop
To restart the entire IdM server:
# ipactl restart
To show the status of all the services that make up IdM:
# ipactl status
You cannot use the IdM web UI to perform the ipactl
commands.
2.4. Starting and stopping an individual Identity Management service: the systemctl
utility
Changing IdM configuration files manually is generally not recommended. However, certain situations require that an administrator performs a manual configuration of specific services. In such situations, use the systemctl
utility to stop, start, or restart an individual IdM service.
For example, use systemctl
after customizing the Directory Server behavior, without modifying the other IdM services:
# systemctl restart dirsrv@REALM-NAME.service
Also, when initially deploying an IdM trust with Active Directory, modify the /etc/sssd/sssd.conf
file, adding:
- specific parameters to tune the timeout configuration options in an environment where remote servers have a high latency
- specific parameters to tune the Active Directory site affinity
- overrides for certain configuration options that are not provided by the global IdM settings
To apply the changes you have made in the /etc/sssd/sssd.conf
file:
# systemctl restart sssd.service
Running systemctl restart sssd.service
is required because the System Security Services Daemon (SSSD) does not automatically re-read or re-apply its configuration.
Note that for changes that affect IdM identity ranges, a complete server reboot is recommended.
To restart multiple IdM domain services, always use ipactl
. Because of dependencies between the services installed with the IdM server, the order in which they are started and stopped is critical. The ipactl
utility ensures that the services are started and stopped in the appropriate order.
Useful systemctl
commands
To start a particular IdM service:
# systemctl start name.service
To stop a particular IdM service:
# systemctl stop name.service
To restart a particular IdM service:
# systemctl restart name.service
To view the status of a particular IdM service:
# systemctl status name.service
You cannot use the IdM web UI to start or stop the individual services running on IdM servers. You can only use the web UI to modify the settings of a Kerberized service by navigating to Identity
→ Services
and selecting the service.
2.5. Methods for displaying IdM software version
You can display the IdM version number with:
- the IdM WebUI
-
ipa
commands -
rpm
commands
- Displaying version through the WebUI
In the IdM WebUI, the software version can be displayed by choosing
About
from the username menu at the top-right.- Displaying version with
ipa
commands From the command line, use the
ipa --version
command.[root@server ~]# ipa --version VERSION: 4.8.0, API_VERSION: 2.233
- Displaying version with
rpm
commands If IdM services are not operating properly, you can use the
rpm
utility to determine the version number of theipa-server
package that is currently installed.[root@server ~]# rpm -q ipa-server ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64
Chapter 3. Introduction to the IdM command-line utilities
The following sections describe the basics of using the Identity Management (IdM) command-line utilities.
Prerequisites
Installed and accessible IdM server.
For details, see Installing Identity Management.
To use the IPA command line interface, authenticate to IdM with a valid Kerberos ticket.
For details about obtaining a valid Kerberos ticket, see Logging in to Identity Management from the command line.
3.1. What is the IPA command line interface
The IPA command line interface (CLI) is the basic command-line interface for Identity Management (IdM) administration.
It supports a lot of subcommands that are used to manage IdM, such as the ipa user-add
command to add a new user.
IPA CLI allows you to:
- Add, manage, or remove users, groups, hosts and other objects in the network.
- Manage certificates.
- Search entries.
- Display and list objects.
- Set access rights.
- Get help with the correct command syntax.
3.2. What is the IPA help
The IPA help is a built-in documentation system for the IdM server.
IPA command line interface (CLI) generates available help topics from loaded IdM plugin modules. If you want to run the IPA help successfully, you need to:
- Have an IdM server installed and running.
- Be authenticated with a valid Kerberos ticket.
Executing the ipa help
command without options displays information about basic help usage and the most common command examples.
Executing help with options has the following syntax:
$ ipa help [TOPIC | COMMAND | topics | commands]
-
[]
— Brackets mean that all parameters are optional and you can write justipa help
and the command will be executed. -
|
— The pipe character means or. Therefore, you can use TOPIC or COMMAND or topics or commands with the basicipa help
command. -
topics
— You can run the commandipa help topics
and it will execute correctly. The command displays a list of topics that are covered by IPA help, for example,user
,cert
,server
and many others. -
TOPIC
— The TOPIC with capital letters means variable, therefore, you can use the particular topic, for example,ipa help user
-
commands
— You can run the commandipa help commands
and it will execute correctly. The command displays a list of commands which are covered by the IPA help, for example,user-add
,ca-enable
,server-show
and many others. -
COMMAND
— The COMMAND with capital letters means variable, therefore, you can use the particular command, for example,ipa help user-add
3.3. Using IPA help topics
The following procedure helps you to understand using the IPA help in the command line interface.
Procedure
- Open terminal and connect to the IdM server.
Enter
ipa help topics
to display a list of topics covered by help.$ ipa help topics
Select one of the topics and create a command according to the following pattern:
ipa help [topic_name]
, instead of thetopic_name
string, add one of the topics you listed in the previous step.In the example, we use the following topic:
user
$ ipa help user
If the IPA help command is too long and you cannot see the whole text, use the following syntax:
$ ipa help user | less
You can then scroll down and read the whole help.
The IPA CLI displays a help page for the user
topic. After reading the overview, you can see many examples with patterns for working with topic commands.
3.4. Using IPA help commands
The following procedure helps you to understand creating the IPA help commands in the command line interface.
Procedure
- Open terminal and connect to the IdM server.
Enter
ipa help commands
to display a list of commands covered by help.$ ipa help commands
Select one of the commands and create a help command according to the following pattern:
ipa help <COMMAND>
, instead of the<COMMAND>
string, add one of the commands you listed in the previous step.$ ipa help user-add
Additional resources
-
For details, see
man ipa
page.
3.5. Structure of IPA commands
The IPA CLI distinguishes the following types of commands:
- Built-in commands — Built-in commands are all available in the IdM server.
- Plug-in provided commands
Structure of IPA commands allows you to manage various types of objects. For example:
- Users,
- Hosts,
- DNS records,
- Certificates,
and many others.
For most of these objects, the IPA CLI includes commands to:
-
Add (
add
) -
Modify (
mod
) -
Delete (
del
) -
Search (
find
) -
Display (
show
)
Commands have the following structure:
ipa user-add
, ipa user-mod
, ipa user-del
, ipa user-find
, ipa user-show
ipa host-add
, ipa host-mod
, ipa host-del
, ipa host-find
, ipa host-show
ipa dnsrecord-add
, ipa dnsrecord-mod
, ipa dnsrecord-del
, ipa dnsrecord-find
, ipa dnrecord-show
You can create a user with the ipa user-add [options]
, where [options]
are optional. If you use just the ipa user-add
command, the script asks you for details one by one.
To change an existing object, you need to define the object, therefore the command includes also object: ipa user-mod USER_NAME [options]
.
3.6. Using an IPA command to add a user account to IdM
The following describes adding a new user to the Identity Management (IdM) database using command line.
Prerequisites
- You need to have administrator privileges to add user accounts to the IdM server.
Procedure
- Open terminal and connect to the IdM server.
Enter the command for adding a new user:
$ ipa user-add
The command runs a script where you can add basic data necessary for creating a user account.
- In the First name: field, enter the first name of the new user and press the Enter key.
- In the Last name: field, enter the last name of the new user and press the Enter key.
In the User login [suggested user name]: enter the user name or just press the Enter key if the suggested user name works for you.
User name must be unique for the whole IdM database. If an error occurs, that the user already exists, you need to start from the beginning with the
ipa user-add
command and try a different user name.
After you successfully added the user name, the user account has been added to the IdM database and the IPA command line interface (CLI) prints on the output the following log:
---------------------- Added user "euser" ---------------------- User login: euser First name: Example Last name: User Full name: Example User Display name: Example User Initials: EU Home directory: /home/euser GECOS: Example User Login shell: /bin/sh Principal name: euser@IDM.EXAMPLE.COM Principal alias: euser@IDM.EXAMPLE.COM Email address: euser@idm.example.com UID: 427200006 GID: 427200006 Password: False Member of groups: ipausers Kerberos keys available: False
As you can see, a user password is not set to the user account. If you want to add also password, use the ipa user-add
command in the following syntax:
$ ipa user-add --first=Example --last=User --password
The IPA CLI then asks you for adding or confirming a user name and password.
If the user has been already created, you can add only the password with the `ipa user-mod`command.
Additional resources
For more information about parameters, enter the following help command to the command line:
$ ipa help user-add
3.7. Using an IPA command to modify a user account in IdM
You can change many parameters for each user account. For example, you can add a new password to the user.
Basic command syntax is different from the user-add
syntax because you need to define the existing user account for which you want to perform changes, for example, add a password.
Prerequisites
- You need to have administrator privileges to modify user accounts in the IdM server.
Procedure
- Open terminal and connect to the IdM server.
Enter the command for adding a password:
$ ipa user-mod euser --password
The command runs a script where you can add the new password.
- Enter the new password and press the Enter key.
After you successfully added the user name, the user account has been added to the IdM database and the IPA CLI prints on the output the following log:
---------------------- Modified user "euser" ---------------------- User login: euser First name: Example Last name: User Home directory: /home/euser Principal name: euser@IDM.EXAMPLE.COM Principal alias: euser@IDM.EXAMPLE.COM Email address: euser@idm.example.com UID: 427200006 GID: 427200006 Password: True Member of groups: ipausers Kerberos keys available: True
The user password is now set for the account and the user can log into IdM.
Additional resources
For more information about parameters, enter the following help command to the command line:
$ ipa help user-mod
3.8. How to supply a list of values to the IdM utilities
Identity Management (IdM) stores values for multi-valued attributes in lists.
IdM supports the following methods of supplying multi-valued lists:
Using the same command-line argument multiple times within the same command invocation:
$ ipa permission-add --right=read --permissions=write --permissions=delete ...
Alternatively, you can enclose the list in curly braces, in which case the shell performs the expansion:
$ ipa permission-add --right={read,write,delete} ...
Examples above show a command permission-add
which adds permissions to an object. The object is not mentioned in the example. Instead of …
you need to add the object for which you want to add permissions.
When you update such multi-valued attributes from the command line, IdM completely overwrites the previous list of values with a new list. Therefore, when updating a multi-valued attribute, you must specify the whole new list, not just a single value you want to add.
In the command above, the list of permissions includes reading, writing and deleting. When you decide to update the list with the permission-mod
command, you must add all values, otherwise those not mentioned will be deleted.
Example 1: — The ipa permission-mod
command updates all previously added permissions.
$ ipa permission-mod --right=read --right=write --right=delete ...
or
$ ipa permission-mod --right={read,write,delete} ...
Example 2 — The ipa permission-mod
command deletes the --right=delete
argument because it is not included in the command:
$ ipa permission-mod --right=read --right=write ...
or
$ ipa permission-mod --right={read,write} ...
3.9. How to use special characters with the IdM utilities
When passing command-line arguments that include special characters to the ipa
commands, escape these characters with a backslash (\). For example, common special characters include angle brackets (< and >), ampersand (&), asterisk (*), or vertical bar (|).
For example, to escape an asterisk (*):
$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg
Commands containing unescaped special characters do not work as expected because the shell cannot properly parse such characters.
Chapter 4. Searching Identity Management entries from the command line
The following sections describe how to use IPA commands, which helps you to find or show objects.
4.1. Overview of listing IdM entries
This section describes the ipa *-find
commands, which can help you to search for a particular type of IdM entries.
To list all the find
commands, use the following ipa help command:
$ ipa help commands | grep find
You may need to check if a particular user is included in the IdM database. You can then list all users with the following command:
$ ipa user-find
To list user groups whose specified attributes contain a keyword:
$ ipa group-find keyword
For example the ipa group-find admin
command lists all groups whose names or descriptions include string admin
:
---------------- 3 groups matched ---------------- Group name: admins Description: Account administrators group GID: 427200002 Group name: editors Description: Limited admins who can edit other users GID: 427200002 Group name: trust admins Description: Trusts administrators group
When searching user groups, you can also limit the search results to groups that contain a particular user:
$ ipa group-find --user=user_name
To search for groups that do not contain a particular user:
$ ipa group-find --no-user=user_name
4.2. Showing details for a particular entry
Use the ipa *-show
command to display details about a particular IdM entry.
Procedure
To display details about a host named server.example.com:
$ ipa host-show server.example.com Host name: server.example.com Principal name: host/server.example.com@EXAMPLE.COM ...
4.3. Adjusting the search size and time limit
Some queries, such as requesting a list of IdM users, can return a very large number of entries. By tuning these search operations, you can improve the overall server performance when running the ipa *-find
commands, such as ipa user-find
, and when displaying corresponding lists in the Web UI.
- Search size limit
Defines the maximum number of entries returned for a request sent to the server from a client’s CLI or from a browser accessing the IdM Web UI.
Default: 100 entries.
- Search time limit
Defines the maximum time (in seconds) that the server waits for searches to run. Once the search reaches this limit, the server stops the search and returns the entries discovered in that time.
Default: 2 seconds.
If you set the values to -1
, IdM will not apply any limits when searching.
Setting search size or time limits too high can negatively affect server performance.
4.3.1. Adjusting the search size and time limit in the command line
The following text describes adjusting search size and time limits in the command line:
- Globally
- For a specific entry
Procedure
To display current search time and size limits in CLI, use the ipa config-show command:
$ ipa config-show Search time limit: 2 Search size limit: 100
To adjust the limits globally for all queries, use the
ipa config-mod
command and add the--searchrecordslimit
and--searchtimelimit
options. For example:$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
-
To adjust the limits only for a specific query, add the
--sizelimit
or--timelimit
options to the command. For example:
$ ipa user-find --sizelimit=200 --timelimit=120
4.3.2. Adjusting the search size and time limit in the Web UI
The following text describes adjusting search size and time limits in the IdM Web UI:
- Globally
- For a specific entry
Procedure
To adjust the limits globally for all queries:
- Log in to the IdM Web UI.
Click IPA Server.
- On the IPA Server tab, click Configuration.
Set the required values in the Search Options area.
Default values are:
- Search size limit: 100 entries
- Search time limit: 2 seconds
Click Save at the top of the page.
After saving the values, search an entry and verify the result.
Chapter 5. Accessing the IdM Web UI in a web browser
The following sections provide an overview of the IdM (Identity Management) Web UI and describe how to access it.
5.1. What is the IdM Web UI
The IdM (Identity Management) Web UI is a web application for IdM administration, a graphical alternative to the IdM command line tools.
You can access the IdM Web UI as:
- IdM users: A limited set of operations depending on permissions granted to the user in the IdM server. Basically, active IdM users can log in to the IdM server and configure their own account. They cannot change settings of other users or the IdM server settings.
- Administrators: Full access rights to the IdM server.
- Active Directory users: A set of operations depending on permissions granted to the user. Active Directory users can now be administrators for Identity Management. For details, see Enabling AD users to administer IdM.
5.2. Web browsers supported for accessing the Web UI
IdM (Identity Management) supports the following browsers for connecting to the Web UI:
- Mozilla Firefox 38 and later
- Google Chrome 46 and later
5.3. Accessing the Web UI
The following procedure describes the first logging in to the IdM (Identity Management) Web UI with a password.
After the first login you can configure your IdM server to authenticate with:
Kerberos ticket
For details, see Section 6.1, “Kerberos authentication in Identity Management”.
Smart card
For details, see Configuring the IdM server for smart card authentication.
One time password (OTP) — this can be combined with password and Kerberos authentication.
For details, see Section 7.2, “One time password (OTP) authentication in Identity Management”.
Procedure
Type an IdM server URL into the browser address bar. The name will look similarly to the following example:
https://server.example.com
You just need to change
server.example.com
with a DNS name of your IdM server.This opens the IdM Web UI login screen in your browser.
- If the server does not respond or the login screen does not open, check the DNS settings on the IdM server to which you are connecting.
If you use a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.
To avoid security exceptions, install a certificate signed by a certificate authority.
On the Web UI login screen, enter the administrator account credentials you added during the IdM server installation.
For details, see Installing an Identity Management server: With integrated DNS, with an integrated CA.
You can enter your personal account credentials as well if they are already entered in the IdM server.
- Click .
After the successful login, you can start configuring the IdM server.
Chapter 6. Logging in to IdM in the Web UI: Using a Kerberos ticket
The following sections describe the initial configuration of your environment to enable Kerberos login to the IdM Web UI and accessing IdM using Kerberos authentication.
Prerequisites
Installed IdM server in your network environment
For details, see Installing Identity Management in Red Hat Enterprise Linux 8
6.1. Kerberos authentication in Identity Management
Identity Management (IdM) uses the Kerberos protocol to support single sign-on. Single sign-on authentication allows you to provide the correct user name and password only once, and you can then access Identity Management services without the system prompting for credentials again.
The IdM server provides Kerberos authentication immediately after the installation if the DNS and certificate settings have been configured properly. For details, see Installing Identity Management.
To use Kerberos authentication on hosts, install:
the IdM client
For details, see Preparing the system for Identity Management client installation.
- the krb5conf package
6.2. Using kinit to log in to IdM manually
This procedure describes using the kinit utility to authenticate to an Identity Management (IdM) environment manually. The kinit utility obtains and caches a Kerberos ticket-granting ticket (TGT) on behalf of an IdM user.
Only use this procedure if you have destroyed your initial Kerberos TGT or if it has expired. As an IdM user, when logging onto your local machine you are also automatically logging in to IdM. This means that after logging in, you are not required to use the kinit utility to access IdM resources.
Procedure
To log in to IdM
under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as
example_user
on the local system:[example_user@server ~]$ kinit Password for example_user@EXAMPLE.COM: [example_user@server ~]$
If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:
[example_user@server ~]$ kinit kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
using a Kerberos principal that does not correspond to your local user name, pass the required user name to the
kinit
utility. For example, to log in as theadmin
user:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the
example_user
principal, which means that on this particular host, onlyexample_user
is currently allowed to access IdM services:$ klist Ticket cache: KEYRING:persistent:0:0 Default principal: example_user@EXAMPLE.COM Valid starting Expires Service principal 11/10/2019 08:35:45 11/10/2019 18:35:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
6.3. Configuring the browser for Kerberos authentication
To enable authentication with a Kerberos ticket, you may need a browser configuration.
The following steps help you to support Kerberos negotiation for accessing the IdM domain.
Each browser supports Kerberos in a different way and needs different set up. The IdM Web UI includes guidelines for the following browsers:
- Firefox
- Chrome
Procedure
- Open the IdM Web UI login dialog in your web browser.
Click the link for browser configuration on the Web UI login screen.
Follow the steps on the configuration page.
After the setup, turn back to the IdM Web UI and click Log in.
6.4. Logging in to the web UI using a Kerberos ticket
This procedure describes logging in to the IdM Web UI using a Kerberos ticket-granting ticket (TGT).
The TGT expires at a predefined time. The default time interval is 24 hours and you can change it in the IdM Web UI.
After the time interval expires, you need to renew the ticket:
- Using the kinit command.
- Using IdM login credentials in the Web UI login dialog.
Procedure
Open the IdM Web UI.
If Kerberos authentication works correctly and you have a valid ticket, you will be automatically authenticated and the Web UI opens.
If the ticket is expired, it is necessary to authenticate yourself with credentials first. However, next time the IdM Web UI will open automatically without opening the login dialog.
If you see an error message
Authentication with Kerberos failed
, verify that your browser is configured for Kerberos authentication. See Section 6.3, “Configuring the browser for Kerberos authentication”.
6.5. Configuring an external system for Kerberos authentication
This section describes how to configure an external system so that Identity Management (IdM) users can log in to IdM from the external system using their Kerberos credentials.
Enabling Kerberos authentication on external systems is especially useful when your infrastructure includes multiple realms or overlapping domains. It is also useful if the system has not been enrolled into any IdM domain through ipa-client-install
.
To enable Kerberos authentication to IdM from a system that is not a member of the IdM domain, define an IdM-specific Kerberos configuration file on the external system.
Prerequisites
The
krb5-workstation
package is installed on the external system.To find out whether the package is installed, use the following CLI command:
# yum list installed krb5-workstation Installed Packages krb5-workstation.x86_64 1.16.1-19.el8 @BaseOS
Procedure
Copy the
/etc/krb5.conf
file from the IdM server to the external system. For example:# scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
WarningDo not overwrite the existing
krb5.conf
file on the external system.On the external system, set the terminal session to use the copied IdM Kerberos configuration file:
$ export KRB5_CONFIG=/etc/krb5_ipa.conf
The
KRB5_CONFIG
variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.-
Copy the Kerberos configuration snippets from the
/etc/krb5.conf.d/
directory to the external system. - Configure the browser on the external system, as described in Section 6.3, “Configuring the browser for Kerberos authentication”.
Users on the external system can now use the kinit
utility to authenticate against the IdM server.
6.6. Web UI login for Active Directory users
To enable Web UI login for Active Directory users, define an ID override for each Active Directory user in the default trust view. For example:
[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com
Chapter 7. Logging in to the Identity Management Web UI using one time passwords
Access to IdM Web UI can be secured using several methods. The basic one is password authentication.
To increase the security of password authentication, you can add a second step and require automatically generated one-time passwords (OTPs). The most common usage is to combine password connected with the user account and a time limited one time password generated by a hardware or software token.
The following sections help you to:
- Understand how the OTP authentication works in IdM.
- Configure OTP authentication on the IdM server.
- Create OTP tokens and synchronize them with the FreeOTP app in your phone.
- Authenticate to the IdM Web UI with the combination of user password and one time password.
- Re-synchronize tokens in the Web UI.
7.1. Prerequisites
7.2. One time password (OTP) authentication in Identity Management
One-time passwords bring an additional step to your authentication security. The authentication uses your password + an automatically generated one time password.
To generate one time passwords, you can use a hardware or software token. IdM supports both software and hardware tokens.
Identity Management 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.
IdM does not support OTP logins for Active Directory trust users.
7.3. Enabling the one time password in the Web UI
The IdM Web UI allows you to configure hardware or software device to generate one-time passwords.
The one time password is entered just after the usual password in the dedicated field in the login dialog.
Only administrators can enable OTP authentication in the user settings.
Prerequisites
- Administration privileges
Procedure
- Log in to the IdM Web UI with your username and password.
Open the Identity → Users → Active users tab.
- Click your username to open the user settings.
- In the User authentication types, select Two factor authentication (password + OTP).
- Click Save.
At this point, the OTP authentication is enabled on the IdM server.
Now you or users themselves need to assign a new token ID to the user account.
7.4. Adding OTP tokens in the Web UI
The following section helps you to add token to the IdM Web UI and to your software token generator.
Prerequisites
- Active user account on the IdM server.
- Administrator has enabled OTP for the particular user account in the IdM Web UI.
- A software device generating OTP tokens, for example FreeOTP.
Procedure
- Log in to the IdM Web UI with your user name and password.
- To create the token in your mobile phone, open the Authentication → OTP Tokens tab.
Click Add.
In the Add OTP token dialog box, leave everything unfilled and click Add.
At this stage, the IdM server creates a token with default parameters at the server and opens a page with a QR code.
- Copy the QR code into your mobile phone.
- Click OK to close the QR code.
Now you can generate one time passwords and log in with them to the IdM Web UI.
7.5. Logging into the Web UI with a one time password
This procedure describes the first login into the IdM Web UI using a one time password (OTP).
Prerequisites
OTP configuration enabled on the Identity Management server for the user account you are using for the OTP authentication. Administrators as well as users themselves can enable OTP.
To enable the OTP configuration, see Section 7.3, “Enabling the one time password in the Web UI”
- A hardware or software device generating OTP tokens configured.
Procedure
- In the Identity Management login screen, enter your user name or a user name of the IdM server administrator account.
- Add the password for the user name entered above.
- Generate a one time password on your device.
- Enter the one time password right after the password (without space).
Click Log in.
If the authentication fails, synchronize OTP tokens.
If your CA uses a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.
If the the IdM Web UI does not open, verify the DNS configuration of your Identity Management server.
After successful login, the IdM Web UI appears.
7.6. Synchronizing OTP tokens using the Web UI
If the login with OTP (One Time Password) fails, OTP tokens are not synchronized correctly.
The following text describes token re-synchronization.
Prerequisites
- A login screen opened.
- A device generating OTP tokens configured.
Procedure
On the IdM Web UI login screen, click Sync OTP Token.
- In the login screen, enter your username and the Identity Management password.
- Generate one time password and enter it in the First OTP field.
- Generate another one time password and enter it in the Second OTP field.
Optionally, enter the token ID.
- Click Sync OTP Token.
After the successful synchronization, you can log in to the IdM server.
7.7. Changing expired passwords
Administrators of Identity Management can enforce you having to change your password at the next login. It means that you cannot successfully log in to the IdM Web UI until you change the password.
Password expiration can happen during your first login to the Web UI.
If the expiration password dialog appears, follow the instructions in the procedure.
Prerequisites
- A login screen opened.
- Active account to the IdM server.
Procedure
- In the password expiration login screen, enter the user name.
- Add the password for the user name entered above.
In the OTP field, generate a one time password, if you use the one time password authentication.
If you do not have enabled the OTP authentication, leave the field empty.
- Enter the new password twice for verification.
Click Reset Password.
After the successful password change, the usual login dialog displays. Log in with the new password.
Chapter 8. Configuring global IdM settings using Ansible playbooks
Using the Ansible config
module, you can retrieve and set global configuration parameters for Identity Management (IdM).
This chapter includes the following sections:
8.1. Retrieving IdM configuration using an Ansible playbook
The following procedure describes how you can use an Ansible playbook to retrieve information about the current global IdM configuration.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and define the IdM server from which you want to retrieve the IdM configuration in the[ipaserver]
section. For example, to instruct Ansible to retrieve the data from server.idm.example.com, enter:[ipaserver] server.idm.example.com
Open the
/usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
Ansible playbook file for editing:--- - name: Playbook to handle global IdM configuration hosts: ipaserver become: no gather_facts: no tasks: - name: Query IPA global configuration ipaconfig: ipaadmin_password: Secret123 register: serverconfig - debug: msg: "{{ serverconfig }}"
Adapt the file by changing the following:
- The password of IdM administrator.
- Other values, if necessary.
- Save the file.
Run the Ansible playbook specifying the playbook file and the inventory file:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml [...] TASK [debug] ok: [server.idm.example.com] => { "msg": { "ansible_facts": { "discovered_interpreter_ }, "changed": false, "config": { "ca_renewal_master_server": "server.idm.example.com", "configstring": [ "AllowNThash", "KDC:Disable Last Success" ], "defaultgroup": "ipausers", "defaultshell": "/bin/bash", "emaildomain": "idm.example.com", "enable_migration": false, "groupsearch": [ "cn", "description" ], "homedirectory": "/home", "maxhostname": "64", "maxusername": "64", "pac_type": [ "MS-PAC", "nfs:NONE" ], "pwdexpnotify": "4", "searchrecordslimit": "100", "searchtimelimit": "2", "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023", "selinuxusermaporder": [ "guest_u:s0$xguest_u:s0$user_ ], "usersearch": [ "uid", "givenname", "sn", "telephonenumber", "ou", "title" ] }, "failed": false } }
8.2. Configuring the IdM CA renewal master server using an Ansible playbook
In an Identity Management (IdM) deployment that uses an embedded certificate authority (CA), the CA renewal master server maintains and renews IdM system certificates. It ensures nondisruptive IdM deployments.
For more details on the role of the IdM CA renewal master, see Using IdM CA renewal master.
The following procedure describes how you can use an Ansible playbook to configure the IdM CA renewal master server.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Optional: Identify the current IdM CA renewal master:
$ ipa config-show | grep 'CA renewal master' IPA CA renewal master: server.idm.example.com
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Open the
/usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml
Ansible playbook file for editing:--- - name: Playbook to handle global DNS configuration hosts: ipaserver become: no gather_facts: no tasks: - name: set ca_renewal_master_server ipaconfig: ipaadmin_password: SomeADMINpassword ca_renewal_master_server: carenewal.idm.example.com
Adapt the file by changing:
-
The password of IdM administrator set by the
ipaadmin_password
variable. -
The name of the master CA server set by the
ca_renewal_master_server
variable.
-
The password of IdM administrator set by the
- Save the file.
Run the Ansible playbook. Specify the playbook file and the inventory file:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml
Verification steps
You can verify that the CA renewal master has been changed:
Log into
ipaserver
as IdM administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request the identity of the IdM master CA server:
$ ipa config-show | grep ‘CA renewal master’ IPA CA renewal master: carenewal.idm.example.com
The output shows the carenewal.idm.example.com server is the new CA renewal master.
8.3. Configuring the default shell for IdM users using an Ansible playbook
The shell is a program that accepts and interprets commands. Several shells are available in Red Hat Enterprise Linux (RHEL), such as bash
, sh
, ksh
, zsh
, fish
, and others. Bash
, or /bin/bash
, is a popular shell on most Linux systems, and it is normally the default shell for user accounts on RHEL.
The following procedure describes how you can use an Ansible playbook to configure sh
, an alternative shell, as the default shell for IdM users.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
-
Optional: Use the
retrieve-config.yml
Ansible playbook to identify the current shell for IdM users. See Retrieving IdM configuration using an Ansible playbook for details. Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Open the
/usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml
Ansible playbook file for editing:--- - name: Playbook to ensure some config options are set hosts: ipaserver become: true tasks: # Set defaultlogin and maxusername - ipaconfig: ipaadmin_password: Secret123 defaultshell: /bin/bash maxusername: 64
Adapt the file by changing the following:
-
The password of IdM administrator set by the
ipaadmin_password
variable. -
The default shell of the IdM users set by the
defaultshell
variable into/bin/sh
.
-
The password of IdM administrator set by the
- Save the file.
Run the Ansible playbook. Specify the playbook file and the inventory file:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml
Verification steps
You can verify that the default user shell has been changed by starting a new session in IdM:
Log into
ipaserver
as IdM administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display the current shell:
[admin@server /]$ echo "$SHELL" /bin/sh
The logged-in user is using the
sh
shell.
Additional resources
-
You can see sample Ansible playbooks for configuring global IdM settings and a list of possible variables in the
README-config.md
Markdown file available in the/usr/share/doc/ansible-freeipa/
directory. -
You can see sample Ansible playbooks for various IdM configuration-related operations in the
/usr/share/doc/ansible-freeipa/playbooks/config
directory.
Chapter 9. Managing user accounts using the command line
This chapter includes basic description of user life cycle in IdM (Identity Management). The following sections show you how to:
- Create user accounts
- Activate stage user accounts
- Preserve user accounts
- Delete active, stage, or preserved user accounts
- Restore preserved user accounts
9.1. User life cycle
IdM (Identity Management) supports three user account states:
- Stage users are not allowed to authenticate. This is an initial state. Some of the user account properties required for active users cannot be set, for example, group membership.
- Active users are allowed to authenticate. All required user account properties must be set in this state.
- Preserved users are former active users that 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.
You can delete user entries permanently from the IdM database.
Deleted user accounts cannot be restored. When you delete a user account, all the information associated with the account is permanently lost.
A new administrator can only be created by a user with administrator rights, 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 Server.
Do not delete the admin
user. As admin
is a pre-defined user required by IdM, this operation causes problems with certain commands. If you want to define and use an alternative admin user, disable the pre-defined admin
user with ipa user-disable admin
after you granted admin permissions to at least one different user.
9.2. Adding users using the command line
You can add user as:
- Active — user accounts which can be actively used by their users.
- Stage — users cannot use these accounts. Use it if you want to prepare new user accounts. When users are ready to use their accounts, then you can activate them.
The following procedure describes adding active users to the IdM server with the ipa user-add
command.
Similarly, you can create stage user accounts with the ipa stageuser-add
command.
IdM automatically assigns a unique user ID (UID) to the new user accounts. You can also do this manually, however, the server does not validate whether the UID number is unique. Due to this, multiple user entries might have the same ID number assigned. Red Hat recommends to prevent having multiple entries with the same UID.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- Obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
- Open terminal and connect to the IdM server.
Add user login, user’s first name, last name and optionally, you can also add their email address.
$ ipa user-add user_login --first=first_name --last=last_name --email=email_address
IdM supports user names that can be described by the following regular expression:
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
NoteUser names ending with the trailing dollar sign ($) are supported to enable Samba 3.x machine support.
If you add a user name containing uppercase characters, IdM automatically converts the name to lowercase when saving it. Therefore, IdM always requires to enter user names in lowercase when logging in. Additionally, it is not possible to add user names which differ only in letter casing, such as user and User.
The default maximum length for user names is 32 characters. To change it, use the
ipa config-mod --maxusername
command. For example, to increase the maximum user name length to 64 characters:$ ipa config-mod --maxusername=64 Maximum username length: 64 ...
The
ipa user-add
command includes a lot of parameters. To list them all, use the ipa help command:$ ipa help user-add
For details about
ipa help
command, see What is the IPA help.
You can verify if the new user account is successfully created by listing all IdM user accounts:
$ ipa $ ipa user-find
This command lists all user accounts with details.
9.3. Activating users using the command line
To activate a user account by moving it from stage to active, use the ipa stageuser-activate
command.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- Obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
- Open terminal and connect to the IdM server.
Activate the user account with the following command:
$ ipa stageuser-activate user_login ------------------------- Stage user user_login activated ------------------------- ...
You can verify if the new user account is successfully created by listing all IdM user accounts:
$ ipa $ ipa user-find
This command lists all user accounts with details.
9.4. Preserving users using the command line
To preserve a user account, use the ipa user-del
or ipa stageuser-del
commands.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- Obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
- Open terminal and connect to the IdM server.
Preserve the user account with the following command:
$ ipa user-del --preserve user_login -------------------- Deleted user "user_login" --------------------
9.5. Deleting users using the command line
IdM (Identity Management) enables you to delete users permanently. You can delete:
-
Active users with the following command:
ipa user-del
-
Stage users with the following command:
ipa stageuser-del
-
Preserved users with the following command:
ipa user-del
When deleting multiple users, use the --continue
option to force the command to continue regardless of errors. A summary of the successful and failed operations is printed to the stdout
standard output stream when the command completes.
$ ipa user-del --continue user1 user2 user3
If you do not use --continue
, the command proceeds with deleting users until it encounters an error, after which it stops and exits.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- Obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
- Open terminal and connect to the IdM server.
Delete the user account with the following command:
$ ipa user-del user_login -------------------- Deleted user "user_login" --------------------
The user account has been permanently deleted from IdM.
9.6. Restoring users using the command line
You can restore a preserved users to:
-
Active users:
ipa user-undel
-
Stage users:
ipa user-stage
Restoring a user account does not restore all of the account’s previous attributes. For example, the user’s password is not restored and must be set again.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- Obtained a Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
- Open terminal and connect to the IdM server.
Activate the user account with the following command:
$ ipa user-undel user_login ------------------------------ Undeleted user account "user_login" ------------------------------
Alternatively, you can restore user accounts as staged:
$ ipa user-stage user_login ------------------------------ Staged user account "user_login" ------------------------------
You can verify if the new user account is successfully created by listing all IdM user accounts:
$ ipa $ ipa user-find
This command lists all user accounts with details.
Chapter 10. Managing user accounts using the IdM Web UI
Identity Management (IdM) provides several stages that can help you to manage various user work life situations:
- Creating a user account
Creating a stage user account before an employee starts their career in your company and be prepared in advance for the day when the employee appears in the office and want to activate the account.
You can omit this step and create the active user account directly. The procedure is similar to creating a stage user account.
- Activating a user account
- Activating the account the first working day of the employee.
- Disabling a user account
- If the user go to a parental leave for couple of months, you will need to disable the account temporarily.
- Enabling a user account
- When the user returns, you will need to re-enable the account.
- Preserving a user account
- If the user wants to leave the company, you will need to delete the account with a possibility to restore it because people can return to the company after some time.
- Restoring a user account
- Two years later, the user is back and you need to restore the preserved account.
- Deleting a user account
- If the employee the employee is dismissed you will delete the account without a backup.
10.1. User life cycle
IdM (Identity Management) supports three user account states:
- Stage users are not allowed to authenticate. This is an initial state. Some of the user account properties required for active users cannot be set, for example, group membership.
- Active users are allowed to authenticate. All required user account properties must be set in this state.
- Preserved users are former active users that 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.
You can delete user entries permanently from the IdM database.
Deleted user accounts cannot be restored. When you delete a user account, all the information associated with the account is permanently lost.
A new administrator can only be created by a user with administrator rights, 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 Server.
Do not delete the admin
user. As admin
is a pre-defined user required by IdM, this operation causes problems with certain commands. If you want to define and use an alternative admin user, disable the pre-defined admin
user with ipa user-disable admin
after you granted admin permissions to at least one different user.
10.2. Adding users in the Web UI
Usually, you need to create a new user account before a new employee starts to work. Such a stage account is not accessible and you need to activate it later.
Alternatively, you can create an active user account directly. For adding active user, follow the procedure below and add the user account in the Active users tab.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
Go to Users → Stage Users tab.
Alternatively, you can add the user account in the Users → Active users, however, you cannot add user groups to the account.
- Click the + Add icon.
- In the Add stage user dialog box, enter First name and Last name of the new user.
[Optional] In the User login field, add a login name.
If you leave it empty, the IdM server creates the login name in the following pattern: The first letter of the first name and the surname. The whole login name can have up to 32 characters.
- [Optional] In the GID drop down menu, select groups in which the user should be included.
- [Optional] In the Password and Verify password fields,
Click on the Add button.
At this point, you can see the user account in the Stage Users table.
If you click on the user name, you can edit advanced settings, such as adding a phone number, address, or occupation.
10.3. Activating stage users in the IdM Web UI
A stage user account must be activated before the user can log in to IdM and before the user can be added to an IdM group. This section describes how to activate stage user accounts.
Prerequisites
- Administrator privileges for managing the IdM Web UI or User Administrator role.
- At least one staged user account in IdM.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
- Go to Users → Stage users tab.
- Click the check-box of the user account you want to activate.
Click on the Activate button.
- In the Confirmation dialog box, click on the OK button.
If the activation is successfull, the IdM Web UI displays a green confirmation that the user has been activated and the user account has been moved to Active users. The account is active and the user can authenticate to the IdM domain and IdM Web UI. The user is prompted to change their password on the first login.
At this stage, you can add the active user account to user groups.
10.4. Disabling user accounts in the Web UI
You can disable active user accounts. Disabling a user account deactivates the account, therefore, user accounts cannot be used to authenticate and using IdM services, such as Kerberos, or perform any tasks.
Disabled user accounts still exist within IdM and all of the associated information remains unchanged. Unlike preserved user accounts, disabled user accounts remain in the active state and can be a member of user groups.
After disabling a user account, any existing connections remain valid until the user’s Kerberos TGT and other tickets expire. After the ticket expires, the user will not be able to renew it.
Prerequisites
- Administrator privileges for managing the IdM Web UI or User Administrator role.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
- Go to Users → Active users tab.
- Click the check-box of the user accounts you want to disable.
Click on the Disable button.
- In the Confirmation dialog box, click on the OK button.
If the disabling procedure has been successful, you can verify in the Status column in the Active users table.
10.5. Enabling user accounts in the Web UI
With IdM you can enable disabled active user accounts. Enabling a user account activates the disabled account.
Prerequisites
- Administrator privileges for managing the IdM Web UI or User Administrator role.
Procedure
- Log in to the IdM Web UI.
- Go to Users → Active users tab.
- Click the check-box of the user accounts you want to enable.
Click on the Enable button.
- In the Confirmation dialog box, click on the OK button.
If the change has been successful, you can verify in the Status column in the Active users table.
10.6. Preserving active users in the IdM Web UI
Preserving user accounts enables you to remove accounts from the Active users tab, yet keeping these accounts in IdM.
Preserve the user account if the employee leaves the company. If you want to disable user accounts for a couple of weeks or months (parental leave, for example), disable the account. For details, see Section 10.4, “Disabling user accounts in the Web UI”. The preserved accounts are not active and users cannot use them to access your internal network, however, the account stays in the database with all the data.
You can move the restored accounts back to the active mode.
The list of users in the preserved state can provide a history of past user accounts.
Prerequisites
- Administrator privileges for managing the IdM (Identity Management) Web UI or User Administrator role.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
- Go to Users → Active users tab.
- Click the check-box of the user accounts you want to preserve.
Click on the Delete button.
- In the Remove users dialog box, switch the Delete mode radio button to preserve.
Click on the Delete button.
As a result, the user account is moved to Preserved users.
If you need to restore preserved users, see the Restoring users in the IdM Web UI.
10.7. Restoring users in the IdM Web UI
IdM (Identity Management) enables you to restore preserved user accounts back in the active state.
Prerequisites
- Administrator privileges for managing the IdM Web UI or User Administrator role.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
- Go to Users → Preserved users tab.
- Click the check-box at the user accounts you want to restore.
Click on the Restore button.
- In the Confirmation dialog box, click on the OK button.
The IdM Web UI displays a green confirmation and moves the user accounts to the Active users tab.
10.8. Deleting users in the IdM Web UI
Deleting users is an irreversible operation, causing the user accounts to be permanently deleted from the IdM database, 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.
You can delete:
Active users — the IdM Web UI offers you with the options:
Preserving users temporarily
For details, see the Preserving active users in the IdM Web UI.
- Deleting them permanently
- Stage users — you can just delete stage users permanently.
- Preserved users — you can delete preserved users permanently.
The following procedure describes deleting active users. Similarly, you can delete user accounts on:
- The Stage users tab
- The Preserved users tab
Prerequisites
- Administrator privileges for managing the IdM Web UI or User Administrator role.
Procedure
Log in to the IdM Web UI.
For details, see Accessing the IdM Web UI in a web browser.
Go to Users → Active users tab.
Alternatively, you can delete the user account in the Users → Stage users or Users → Preserved users.
- Click the Delete icon.
- In the Remove users dialog box, switch the Delete mode radio button to delete.
- Click on the Delete button.
The users accounts have been permanently deleted from IdM.
Chapter 11. Managing user accounts using Ansible playbooks
You can manage users in IdM using Ansible playbooks. This chapter describes using Ansible playbooks for the following operations:
-
Ensuring the presence of a single user listed directly in the
YML
file. -
Ensuring the presence of multiple users listed directly in the
YML
file. -
Ensuring the presence of multiple users listed in a
JSON
file that is referenced from theYML
file. -
Ensuring the absence of users listed directly in the
YML
file.
11.1. Ensuring the presence of an IdM user using an Ansible playbook
The following procedure describes ensuring the presence of a user in IdM using an Ansible playbook.
Prerequisites
- You know the IdM administator password.
- The ansible-freeipa package is installed on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the data of the user whose presence in IdM you want to ensure. To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml
file. For example, to create user named idm_user and add Password123 as the user password:--- - name: Playbook to handle users hosts: ipaserver become: true tasks: - name: Create user idm_user ipauser: ipaadmin_password: MySecret123 name: idm_user first: Alice last: Acme uid: 1000111 gid: 10011 phone: "+555123457" email: idm_user@acme.com passwordexpiration: "2023-01-19 23:59:59" password: "Password123" update_password: on_create
You must use the following options to add a user:
- name: the login name
- first: the first name string
- last: the last name string
For the full list of available user options, see the
/usr/share/doc/ansible-freeipa/README-user.md
Markdown file.NoteIf you use the
update_password: on_create
option, Ansible only creates the user password when it creates the user. If the user is already created with a password, Ansible does not generate a new password.Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml
Verification steps
You can verify if the new user account exists in IdM by using the
ipa user-show
command:Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Request information about idm_user:
$ ipa user-show idm_user User login: idm_user First name: Alice Last name: Acme ....
The user named idm_user is present in IdM.
11.2. Ensuring the presence of multiple IdM users using Ansible playbooks
The following procedure describes ensuring the presence of multiple users in IdM using an Ansible playbook.
Prerequisites
- You know the IdM administator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the data of the users whose presence you want to ensure in IdM. To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml
file. For example, to create users idm_user_1, idm_user_2, and idm_user_3, and add Password123 as the password of idm_user_1:--- - name: Playbook to handle users hosts: ipaserver become: true tasks: - name: Create user idm_users ipauser: ipaadmin_password: MySecret123 users: - name: idm_user_1 first: Alice last: Acme uid: 10001 gid: 10011 phone: "+555123457" email: idm_user@acme.com passwordexpiration: "2023-01-19 23:59:59" password: "Password123" - name: idm_user_2 first: Bob last: Acme uid: 100011 gid: 10011 - name: idm_user_3 first: Eve last: Acme uid: 1000111 gid: 10011
NoteIf you do not specify the update_password: on_create option, Ansible re-sets the user password every time the playbook is run: if the user has changed the password since the last time the playbook was run, Ansible re-sets password.
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml
Verification steps
You can verify if the user account exists in IdM by using the
ipa user-show
command:Log into
ipaserver
as administrator:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
Display information about idm_user_1:
$ ipa user-show idm_user_1 User login: idm_user_1 First name: Alice Last name: Acme Password: True ....
The user named idm_user_1 is present in IdM.
11.3. Ensuring the presence of multiple IdM users from a JSON file using Ansible playbooks
The following procedure describes how you can ensure the presence of multiple users in IdM using an Ansible playbook. The users are stored in a JSON
file.
Prerequisites
- You know the IdM administator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary tasks. Reference the
JSON
file with the data of the users whose presence you want to ensure. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml
file:--- - name: Ensure users' presence hosts: ipaserver become: true tasks: - name: Include users.json include_vars: file: users.json - name: Users present ipauser: ipaadmin_password: MySecret123 users: "{{ users }}"
Create the
users.json
file, and add the IdM users into it. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/user/users.json
file. For example, to create users idm_user_1, idm_user_2, and idm_user_3, and add Password123 as the password of idm_user_1:{ "users": [ { "name": "idm_user_1", "first": "Alice", "last": "Acme", "password": "Password123" }, { "name": "idm_user_2", "first": "Bob", "last": "Acme" }, { "name": "idm_user_3", "first": "Eve", "last": "Acme" } ] }
Run the Ansible playbook specifying the playbook file and the inventory file:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml
Verification steps
You can verify if the user accounts are present in IdM using the
ipa user-show
command:Log into
ipaserver
as administrator:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
Display information about idm_user_1:
$ ipa user-show idm_user_1 User login: idm_user_1 First name: Alice Last name: Acme Password: True ....
The user named idm_user_1 is present in IdM.
11.4. Ensuring the absence of users using Ansible playbooks
The following procedure describes how you can use an Ansible playbook to ensure that specific users are absent from IdM.
Prerequisites
- You know the IdM administator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the users whose absence from IdM you want to ensure. To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml
file. For example, to delete users idm_user_1, idm_user_2, and idm_user_3:--- - name: Playbook to handle users hosts: ipaserver become: true tasks: - name: Delete users idm_user_1, idm_user_2, idm_user_3 ipauser: ipaadmin_password: MySecret123 users: - name: idm_user_1 - name: idm_user_2 - name: idm_user_3 state: absent
Run the Ansible playbook specifying the playbook file and the inventory file:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml
Verification steps
You can verify that the user accounts do not exist in IdM by using the ipa user-show
command:
Log into
ipaserver
as administrator:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
Request information about idm_user_1:
$ ipa user-show idm_user_1 ipa: ERROR: idm_user_1: user not found
The user named idm_user_1 does not exist in IdM.
Additional resources
-
You can see sample Ansible playbooks for other IdM user-related actions such as preserving, deleting, enabling, disabling, unlocking and undeleting users in the README-user.md Markdown file available in the
/usr/share/doc/ansible-freeipa/
directory. The file also contains the definitions ofipauser
variables. -
You can also see sample Ansible playbooks in the
/usr/share/doc/ansible-freeipa/playbooks/user
directory.
Chapter 12. Managing user groups in IdM CLI
This chapter introduces user groups management using the IdM CLI.
A user group is a set of users with common privileges, password policies, and other characteristics.
A user group in Identity Management (IdM) can include:
- IdM users
- other IdM user groups
- external users, which are users that exist outside of IdM
12.1. The different group types in IdM
IdM supports the following types of groups:
- POSIX groups (the default)
POSIX groups support Linux POSIX attributes for their members. Note that groups that interact with Active Directory cannot use POSIX attributes.
POSIX attributes identify users as separate entities. Examples of POSIX attributes relevant to users include
uidNumber
, a user number (UID), andgidNumber
, a group number (GID).- Non-POSIX groups
Non-POSIX groups do not support POSIX attributes. For example, these groups do not have a GID defined.
All members of this type of group must belong to the IdM domain.
- External groups
Use external groups to add group members that exist in an identity store outside of the IdM domain, such as:
- A local system
- An Active Directory domain
- A directory service
External groups do not support POSIX attributes. For example, these groups do not have a GID defined.
Table 12.1. User groups created by default
Group name | Default group members |
---|---|
| All IdM users |
|
Users with administrative privileges, including the default |
| This is a legacy group that no longer has any special privileges |
| Users with privileges to manage the Active Directory trusts |
When you add a user to a user group, the user gains the privileges and policies associated with the group. For example, to grant administrative privileges to a user, add the user to the admins
group.
Do not delete the admins
group. As admins
is a pre-defined group required by IdM, this operation causes problems with certain commands.
In addition, IdM creates user private groups by default whenever a new user is created in IdM. For more information about private groups, see Adding users without a private group.
12.2. Direct and indirect group members
User group attributes in IdM apply to both direct and indirect members: when group B is a member of group A, all users in group B are considered indirect members of group A.
For example, in the following diagram:
- User 1 and User 2 are direct members of group A.
- User 3, User 4, and User 5 are indirect members of group A.
Figure 12.1. Direct and Indirect Group Membership

If you set a password policy for user group A, the policy also applies to all users in user group B.
12.3. Adding a user group using IdM CLI
This section describes how to add a user group using IdM CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
Add a user group by using the
ipa group-add group_name
command. For example, to create group_a:$ ipa group-add group_a --------------------- Added group "group_a" --------------------- Group name: group_a GID: 1133400009
By default,
ipa group-add
adds a POSIX user group. To specify a different group type, add options toipa group-add
:-
--nonposix
to create a non-POSIX group --external
to create an external groupFor details on group types, see The different group types in IdM.
You can specify a custom GID when adding a user group by using the
--gid=custom_GID
option. If you do this, be careful to avoid ID conflicts. If you do not specify a custom GID, IdM automatically assigns a GID from the available ID range.-
12.4. Searching for user groups using IdM CLI
This section describes how to search for existing user groups using IdM CLI.
Procedure
Display all user groups by using the
ipa group-find
command. To specify a group type, add options toipa group-find
:-
Display all POSIX groups using the
ipa group-find --posix
command. -
Display all non-POSIX groups using the
ipa group-find --nonposix
command. Display all external groups using the
ipa group-find --external
command.For more information on different group types, see The different group types in IdM.
-
Display all POSIX groups using the
12.5. Deleting a user group using IdM CLI
This section describes how to delete a user group using IdM CLI. Note that deleting a group does not delete the group members from IdM.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
Delete a user group by using the
ipa group-del group_name
command. For example, to delete group_a:$ ipa group-del group_a -------------------------- Deleted group "group_a" --------------------------
12.6. Adding a member to a user group using IdM CLI
This section describes how to add a member to a user group using IdM CLI. You can add both users and user groups as members of a user group. For more information, see The different group types in IdM and Direct and indirect group members.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
Add a member to a user group by using the
ipa group-add-member
command.Specify the type of member using these options:
-
--users
adds an IdM user -
--external
adds a user that exists outside the IdM domain, in the format ofDOMAIN\user_name
oruser_name@domain
-
--groups
adds an IdM user group
For example, to add group_b as a member of group_a:
$ ipa group-add-member group_a --groups=group_b Group name: group_a GID: 1133400009 Member users: user_a Member groups: group_b Indirect Member users: user_b ------------------------- Number of members added 1 -------------------------
Members of group_b are now indirect members of group_a.
-
When adding a group as a member of another group, do not create recursive groups. For example, if Group A is a member of Group B, do not add Group B as a member of Group A. Recursive groups can cause unpredictable behavior.
After you add a member to a user group, the update may take some time to spread to all clients in your Identity Management environment. This is because when any given host resolves users, groups and netgroups, the System Security Services Daemon
(SSSD) first looks into its cache and performs server lookups only for missing or expired records.
12.7. Adding users without a user private group
By default, IdM creates user private groups (UPGs) whenever a new user is created in IdM. UPGs are a specific group type:
- The UPG has the same name as the newly created user.
- The user is the only member of the UPG. The UPG cannot contain any other members.
- The GID of the private group matches the UID of the user.
However, it is possible to add users without creating a UPG.
12.7.1. Users without a user private group
If a NIS group or another system group already uses the GID that would be assigned to a user private group, it is necessary to avoid creating a UPG.
You can do this in two ways:
- Add a new user without a UPG, without disabling private groups globally. See Adding a user without a user private group when private groups are globally enabled.
- Disable UPGs globally for all users, then add a new user. See Disabling user private groups globally for all users and Adding a user when user private groups are globally disabled.
In both cases, IdM will require specifying a GID when adding new users, otherwise the operation will fail. This is because IdM requires a GID for the new user, but the default user group ipausers
is a non-POSIX group and therefore does not have an associated GID. The GID you specify does not have to correspond to an already existing group.
Specifying the GID does not create a new group. It only sets the GID attribute for the new user, because the attribute is required by IdM.
12.7.2. Adding a user without a user private group when private groups are globally enabled
You can add a user without creating a user private group (UPG) even when UPGs are enabled on the system. This requires manually setting a GID for the new user. For details on why this is needed, see Section 12.7.1, “Users without a user private group”.
Procedure
To prevent IdM from creating a UPG, add the
--noprivate
option to theipa user-add
command.Note that for the command to succeed, you must specify a custom GID. For example, to add a new user with GID 10000:
$ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000
12.7.3. Disabling user private groups globally for all users
You can disable user private groups (UPGs) globally. This prevents the creation of UPGs for all new users. Existing users are unaffected by this change.
Procedure
Obtain administrator privileges:
$ kinit admin
IdM uses the Directory Server Managed Entries Plug-in to manage UPGs. List the instances of the plug-in:
$ ipa-managed-entries --list
To ensure IdM does not create UPGs, disable the plug-in instance responsible for managing user private groups:
$ ipa-managed-entries -e "UPG Definition" disable Disabling Plugin
NoteTo re-enable the
UPG Definition
instance later, use theipa-managed-entries -e "UPG Definition" enable
command.Restart Directory Server to load the new configuration.
$ sudo systemctl restart dirsrv.target
To add a user after UPGs have been disabled, you need to specify a GID. For more information, see Adding a user when user private groups are globally disabled
Verification steps
To check if UPGs are globally disabled, use the disable command again:
$ ipa-managed-entries -e "UPG Definition" disable Plugin already disabled
12.7.4. Adding a user when user private groups are globally disabled
When user private groups (UPGs) are disabled globally, IdM does not assign a GID to a new user automatically. To successfully add a user, you must assign a GID manually or by using an automember rule. For details on why this is required, see Section 12.7.1, “Users without a user private group”.
Prerequisities
- UPGs must be disabled globally for all users. For more information, see Disabling user private groups globally for all users
Procedure
To make sure adding a new user succeeds when creating UPGs is disabled, choose one of the following:
Specify a custom GID when adding a new user. The GID does not have to correspond to an already existing user group.
For example, when adding a user from the command line, add the
--gid
option to theipa user-add
command.- Use an automember rule to add the user to an existing group with a GID.
12.8. Adding users or groups as member managers to an IdM user group using the IdM CLI
This section describes how to add users or groups as member managers to an IdM user group using the IdM CLI. Member managers can add users or groups to IdM user groups but cannot change the attributes of a group.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
- You must have the name of the user or group you are adding as member managers and the name of the group you want them to manage.
Procedure
Add a user as a member manager to an IdM user group by using the
ipa group-add-member-manager
command.For example, to add the user
test
as a member manager ofgroup_a
:$ ipa group-add-member-manager group_a --users=test Group name: group_a GID: 1133400009 Membership managed by users: test ------------------------- Number of members added 1 -------------------------
User
test
can now manage members ofgroup_a
.Add a group as a member manager to an IdM user group by using the
ipa group-add-member-manager
command.For example, to add the group
group_admins
as a member manager ofgroup_a
:$ ipa group-add-member-manager group_a --groups=group_admins Group name: group_a GID: 1133400009 Membership managed by groups: group_admins Membership managed by users: test ------------------------- Number of members added 1 -------------------------
Group
group_admins
can now manage members ofgroup_a
.
After you add a member manager to a user group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Using the
ipa group-show
command to verify the user and group were added as member managers.$ ipa group-show group_a Group name: group_a GID: 1133400009 Membership managed by groups: group_admins Membership managed by users: test
Additional resources
-
See
ipa group-add-member-manager --help
for more details.
12.9. Viewing group members using IdM CLI
This section describes how to view members of a group using IdM CLI. You can view both direct and indirect group members. For more information, see Direct and indirect group members.
Procedure:
To list members of a group, use the
ipa group-show group_name
command. For example:$ ipa group-show group_a ... Member users: user_a Member groups: group_b Indirect Member users: user_b
NoteThe list of indirect members does not include external users from trusted Active Directory domains. The Active Directory trust user objects are not visible in the Identity Management interface because they do not exist as LDAP objects within Identity Management.
12.10. Removing a member from a user group using IdM CLI
This section describes how to remove a member from a user group using IdM CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
-
Optional. Use the
ipa group-show
command to confirm that the group includes the member you want to remove. Remove a member from a user group by using the
ipa group-remove-member
command.Specify members to remove using these options:
-
--users
removes an IdM user -
--external
removes a user that exists outside the IdM domain, in the format ofDOMAIN\user_name
oruser_name@domain
-
--groups
removes an IdM user group
For example, to remove user1, user2, and group1 from a group called group_name:
$ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1
-
12.11. Removing users or groups as member managers from an IdM user group using the IdM CLI
This section describes how to remove users or groups as member managers from an IdM user group using the IdM CLI. Member managers can remove users or groups from IdM user groups but cannot change the attributes of a group.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
- You must have the name of the existing member manager user or group you are removing and the name of the group they are managing.
Procedure
Remove a user as a member manager of an IdM user group by using the
ipa group-remove-member-manager
command.For example, to remove the user
test
as a member manager ofgroup_a
:$ ipa group-remove-member-manager group_a --users=test Group name: group_a GID: 1133400009 Membership managed by groups: group_admins --------------------------- Number of members removed 1 ---------------------------
User
test
can no longer manage members ofgroup_a
.Remove a group as a member manager of an IdM user group by using the
ipa group-remove-member-manager
command.For example, to remove the group
group_admins
as a member manager ofgroup_a
:$ ipa group-remove-member-manager group_a --groups=group_admins Group name: group_a GID: 1133400009 --------------------------- Number of members removed 1 ---------------------------
Group
group_admins
can no longer manage members ofgroup_a
.
After you remove a member manager from a user group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Using the
ipa group-show
command to verify the user and group were removed as member managers.$ ipa group-show group_a Group name: group_a GID: 1133400009
Additional resources
-
See
ipa group-remove-member-manager --help
for more details.
Chapter 13. Managing user groups in IdM Web UI
This chapter introduces user groups management using the IdM web UI.
A user group is a set of users with common privileges, password policies, and other characteristics.
A user group in Identity Management (IdM) can include:
- IdM users
- other IdM user groups
- external users, which are users that exist outside of IdM
13.1. The different group types in IdM
IdM supports the following types of groups:
- POSIX groups (the default)
POSIX groups support Linux POSIX attributes for their members. Note that groups that interact with Active Directory cannot use POSIX attributes.
POSIX attributes identify users as separate entities. Examples of POSIX attributes relevant to users include
uidNumber
, a user number (UID), andgidNumber
, a group number (GID).- Non-POSIX groups
Non-POSIX groups do not support POSIX attributes. For example, these groups do not have a GID defined.
All members of this type of group must belong to the IdM domain.
- External groups
Use external groups to add group members that exist in an identity store outside of the IdM domain, such as:
- A local system
- An Active Directory domain
- A directory service
External groups do not support POSIX attributes. For example, these groups do not have a GID defined.
Table 13.1. User groups created by default
Group name | Default group members |
---|---|
| All IdM users |
|
Users with administrative privileges, including the default |
| This is a legacy group that no longer has any special privileges |
| Users with privileges to manage the Active Directory trusts |
When you add a user to a user group, the user gains the privileges and policies associated with the group. For example, to grant administrative privileges to a user, add the user to the admins
group.
Do not delete the admins
group. As admins
is a pre-defined group required by IdM, this operation causes problems with certain commands.
In addition, IdM creates user private groups by default whenever a new user is created in IdM. For more information about private groups, see Adding users without a private group.
13.2. Direct and indirect group members
User group attributes in IdM apply to both direct and indirect members: when group B is a member of group A, all users in group B are considered indirect members of group A.
For example, in the following diagram:
- User 1 and User 2 are direct members of group A.
- User 3, User 4, and User 5 are indirect members of group A.
Figure 13.1. Direct and Indirect Group Membership

If you set a password policy for user group A, the policy also applies to all users in user group B.
13.3. Adding a user group using IdM Web UI
This section describes how to add a user group using the IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
Procedure
- Click Identity → Groups, and select User Groups in the left sidebar.
- Click Add to start adding the group.
Fill out the information about the group. For more information about user group types, see The different group types in IdM.
You can specify a custom GID for the group. If you do this, be careful to avoid ID conflicts. If you do not specify a custom GID, IdM automatically assigns a GID from the available ID range.
- Click Add to confirm.
13.4. Deleting a user group using IdM Web UI
This section describes how to delete a user group using the IdM Web UI. Note that deleting a group does not delete the group members from IdM.
Prerequisites
- You are logged in to the IdM Web UI.
Procedure
- Click Identity → Groups and select User Groups.
- Select the group to delete.
- Click Delete.
- Click Delete to confirm.
13.5. Adding a member to a user group using IdM Web UI
You can add both users and user groups as members of a user group. For more information, see The different group types in IdM and Direct and indirect group members.
Prerequisites
- You are logged in to the IdM Web UI.
Procedure
- Click Identity → Groups and select User Groups in the left sidebar.
- Click the name of the group.
Select the type of group member you want to add: Users, User Groups, or External.
- Click Add.
- Select the check box next to one or more members you want to add.
Click the rightward arrow to move the selected members to the group.
- Click Add to confirm.
13.6. Adding users or groups as member managers to an IdM user group using the Web UI
This section describes how to add users or groups as member managers to an IdM user group using the Web UI. Member managers can add users or groups to IdM user groups but cannot change the attributes of a group.
Prerequisites
- You are logged in to the IdM Web UI.
- You must have the name of the user or group you are adding as member managers and the name of the group you want them to manage.
Procedure
- Click Identity → Groups and select User Groups in the left sidebar.
- Click the name of the group.
Select the type of group member manager you want to add: Users or User Groups.
- Click Add.
- Select the check box next to one or more members you want to add.
Click the rightward arrow to move the selected members to the group.
- Click Add to confirm.
After you add a member manager to a user group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Verify the newly added user or user group has been added to the member manager list of users or user groups:
Additional resources
-
See
ipa group-add-member-manager --help
for more information.
13.7. Viewing group members using IdM Web UI
This section describes how to view members of a group using the IdM Web UI. You can view both direct and indirect group members. For more information, see Direct and indirect group members.
Prerequisites
- You are logged in to the IdM Web UI.
Procedure
- Select Identity → Groups.
- Select User Groups in the left sidebar.
- Click the name of the group you want to view.
Switch between Direct Membership and Indirect Membership.
13.8. Removing a member from a user group using IdM Web UI
This section describes how to remove a member from a user group using the IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
Procedure
- Click Identity → Groups and select User Groups in the left sidebar.
- Click the name of the group.
Select the type of group member you want to remove: Users, User Groups, or External.
- Select the check box next to the member you want to remove.
- Click Delete.
- Click Delete to confirm.
13.9. Removing users or groups as member managers from an IdM user group using the Web UI
This section describes how to remove users or groups as member managers from an IdM user group using the Web UI. Member managers can remove users or groups from IdM user groups but cannot change the attributes of a group.
Prerequisites
- You are logged in to the IdM Web UI.
- You must have the name of the existing member manager user or group you are removing and the name of the group they are managing.
Procedure
- Click Identity → Groups and select User Groups in the left sidebar.
- Click the name of the group.
Select the type of member manager you want to remove: Users or User Groups.
- Select the check box next to the member manager you want to remove.
- Click Delete.
- Click Delete to confirm.
After you remove a member manager from a user group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Verify the user or user group has been removed from the member manager list of users or user groups:
Additional resources
-
See
ipa group-add-member-manager --help
for more details.
Chapter 14. Managing User Groups using Ansible Playbooks
This section introduces user group management using Ansible playbooks, including the following:
14.1. Ensuring the presence of IdM groups and group members using Ansible playbooks
The following procedure describes ensuring the presence of IdM groups and group members - both users and user groups - using an Ansible playbook.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- The users you want to reference in your Ansible playbook exist in IdM. For details on ensuring the presence of users using Ansible, see Managing user accounts using Ansible playbooks.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary user and group information:
--- - name: Playbook to handle groups hosts: ipaserver become: true tasks: - name: Create group ops with gid 1234 ipagroup: ipaadmin_password: MySecret123 name: ops gidnumber: 1234 - name: Create group sysops ipagroup: ipaadmin_password: MySecret123 name: sysops user: - idm_user - name: Create group appops ipagroup: ipaadmin_password: MySecret123 name: appops - name: Add group members sysops and appops to group ops ipagroup: ipaadmin_password: MySecret123 name: ops group: - sysops - appops
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml
Verification steps
You can verify if the ops group contains sysops and appops as direct members and idm_user as an indirect member by using the ipa group-show
command:
Log into
ipaserver
as administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about ops:
ipaserver]$ ipa group-show ops Group name: ops GID: 1234 Member groups: sysops, appops Indirect Member users: idm_user
The appops and sysops groups - the latter including the idm_user user - exist in IdM.
Additional resources
-
For more information about ensuring the presence of user groups using Ansible, see the
/usr/share/doc/ansible-freeipa/README-group.md
Markdown file.
14.2. Ensuring the presence of member managers in IdM user groups using Ansible playbooks
The following procedure describes ensuring the presence of IdM member managers - both users and user groups - using an Ansible playbook.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- You must have the name of the user or group you are adding as member managers and the name of the group you want them to manage.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary user and group member management information:
--- - name: Playbook to handle membership management hosts: ipaserver become: true tasks: - name: Ensure user test is present for group_a ipagroup: ipaadmin_password: MySecret123 name: group_a membermanager_user: test - name: Ensure group_admins is present for group_a ipagroup: ipaadmin_password: MySecret123 name: group_a membermanager_group: group_admins
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml
Verification steps
You can verify if the group_a group contains test as a member manager and group_admins is a member manager of group_a by using the ipa group-show
command:
Log into
ipaserver
as administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about managergroup1:
ipaserver]$ ipa group-show group_a Group name: group_a GID: 1133400009 Membership managed by groups: group_admins Membership managed by users: test
Additional resources
-
See
ipa host-add-member-manager --help
. -
See the
ipa
man page.
14.3. Ensuring the absence of member managers in IdM user groups using Ansible playbooks
The following procedure describes ensuring the absence of IdM member managers - both users and user groups - using an Ansible playbook.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- You must have the name of the existing member manager user or group you are removing and the name of the group they are managing.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary user and group member management information:
--- - name: Playbook to handle membership management hosts: ipaserver become: true tasks: - name: Ensure member manager user and group members are absent for group_a ipagroup: ipaadmin_password: MySecret123 name: group_a membermanager_user: test membermanager_group: group_admins action: member state: absent
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml
Verification steps
You can verify if the group_a group does not contain test as a member manager and group_admins as a member manager of group_a by using the ipa group-show
command:
Log into
ipaserver
as administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about group_a:
ipaserver]$ ipa group-show group_a Group name: group_a GID: 1133400009
Additional resources
-
See
ipa host-remove-member-manager --help
. -
See the
ipa
man page.
Chapter 15. Automating group membership using IdM CLI
Using automatic group membership allows you to assign users and hosts to groups automatically based on their attributes. For example, you can:
- Divide employees' user entries into groups based on the employees' manager, location, or any other attribute.
- Divide hosts based on their class, location, or any other attribute.
- Add all users or all hosts to a single global group.
This chapter covers the following topics:
- Benefits of automatic group membership
- Automember rules
- Adding an automember rule using IdM CLI
- Adding a condition to an automember rule using IdM CLI
- Viewing existing automember rules using IdM CLI
- Deleting an automember rule using IdM CLI
- Removing a condition from an automember rule using IdM CLI
- Applying automember rules to existing entries using IdM CLI
- Configuring a default automember group using IdM CLI
15.1. Benefits of automatic group membership
Using automatic membership for users allows you to:
Reduce the overhead of manually managing group memberships
You no longer have to assign every user and host to groups manually.
Improve consistency in user and host management
Users and hosts are assigned to groups based on strictly defined and automatically evaluated criteria.
Simplify the management of group-based settings
Various settings are defined for groups and then applied to individual group members, for example
sudo
rules, automount, or access control. Adding users and hosts to groups automatically makes managing these settings easier.
15.2. Automember rules
When configuring automatic group membership, the administrator defines automember rules. An automember rule applies to a specific user or host target group. It cannot apply to more than one group at a time.
After creating a rule, the administrator adds conditions to it. These specify which users or hosts get included or excluded from the target group:
Inclusive conditions
When a user or host entry meets an inclusive condition, it will be included in the target group.
Exclusive conditions
When a user or host entry meets an exclusive condition, it will not be included in the target group.
The conditions are specified as regular expressions in the Perl-compatible regular expressions (PCRE) format. For more information on PCRE, see the pcresyntax(3) man page.
IdM evaluates exclusive conditions before inclusive conditions. In case of a conflict, exclusive conditions take precedence over inclusive conditions.
An automember rule applies to every entry created in the future. These entries will be automatically added to the specified target group. If an entry meets the conditions specified in multiple automember rules, it will be added to all the corresponding groups.
Existing entries are not affected by the new rule. If you want to change existing entries, see Applying automember rules to existing entries using IdM CLI.
15.3. Adding an automember rule using IdM CLI
This section describes adding an automember rule using the IdM CLI. For information about automember rules, see Automember rules.
After adding an automember rule, you can add conditions to it using the procedure described in Adding a condition to an automember rule.
Existing entries are not affected by the new rule. If you want to change existing entries, see Applying automember rules to existing entries using IdM CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
- The target group of the new rule must exist in IdM.
Procedure
-
Enter the
ipa automember-add
command to add an automember rule. When prompted, specify:
- Automember rule. This is the target group name.
- Grouping Type. This specifies whether the rule targets a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.
For example, to add an automember rule for a user group named user_group:
$ ipa automember-add Automember Rule: user_group Grouping Type: group -------------------------------- Added automember rule "user_group" -------------------------------- Automember Rule: user_group
Verification steps
- You can display existing automember rules and conditions in IdM using Viewing existing automember rules using IdM CLI.
15.4. Adding a condition to an automember rule using IdM CLI
This section describes how to add a condition to an automember rule using the IdM CLI. For information about automember rules, see Automember rules.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
- The target rule must exist in IdM. For details, see Adding an automember rule using IdM CLI.
Procedure
-
Define one or more inclusive or exclusive conditions using the
ipa automember-add-condition
command. When prompted, specify:
- Automember rule. This is the target rule name. See Automember rules for details.
- Attribute Key. This specifies the entry attribute to which the filter will apply. For example, uid for users.
- Grouping Type. This specifies whether the rule targets a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.
- Inclusive regex and Exclusive regex. These specify one or more conditions as regular expressions. If you only want to specify one condition, press Enter when prompted for the other.
For example, the following condition targets all users with any value (.*) in their user login attribute (uid).
$ ipa automember-add-condition Automember Rule: user_group Attribute Key: uid Grouping Type: group [Inclusive Regex]: .* [Exclusive Regex]: ---------------------------------- Added condition(s) to "user_group" ---------------------------------- Automember Rule: user_group Inclusive Regex: uid=.* ---------------------------- Number of conditions added 1 ----------------------------
As another example, you can use an automembership rule to target all Windows users synchronized from Active Directory (AD). To achieve this, create a condition that that targets all users with ntUser in their objectClass attribute, which is shared by all AD users:
$ ipa automember-add-condition Automember Rule: ad_users Attribute Key: objectclass Grouping Type: group [Inclusive Regex]: ntUser [Exclusive Regex]: ------------------------------------- Added condition(s) to "ad_users" ------------------------------------- Automember Rule: ad_users Inclusive Regex: objectclass=ntUser ---------------------------- Number of conditions added 1 ----------------------------
Verification steps
- You can display existing automember rules and conditions in IdM using Viewing existing automember rules using IdM CLI.
15.5. Viewing existing automember rules using IdM CLI
This section describes how to view existing automember rules using the IdM CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
-
Enter the
ipa automember-find
command. When prompted, specify the Grouping type:
- To target a user group, enter group.
To target a host group, enter hostgroup.
For example:
$ ipa automember-find Grouping Type: group --------------- 1 rules matched --------------- Automember Rule: user_group Inclusive Regex: uid=.* ---------------------------- Number of entries returned 1 ----------------------------
15.6. Deleting an automember rule using IdM CLI
This section describes how to delete an automember rule using the IdM CLI.
Deleting an automember rule also deletes all conditions associated with the rule. To remove only specific conditions from a rule, see Removing a condition from an automember rule using IdM CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
-
Enter the
ipa automember-del
command. When prompted, specify:
- Automember rule. This is the rule you want to delete.
- Grouping rule. This specifies whether the rule you want to delete is for a user group or a host group. Enter group or hostgroup.
15.7. Removing a condition from an automember rule using IdM CLI
This section describes how to remove a specific condition from an automember rule.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
-
Enter the
ipa automember-remove-condition
command. When prompted, specify:
- Automember rule. This is the name of the rule from which you want to remove a condition.
- Attribute Key. This is the target entry attribute. For example, uid for users.
- Grouping Type. This specifies whether the condition you want to delete is for a user group or a host group. Enter group or hostgroup.
Inclusive regex and Exclusive regex. These specify the conditions you want to remove. If you only want to specify one condition, press Enter when prompted for the other.
For example:
$ ipa automember-remove-condition Automember Rule: user_group Attribute Key: uid Grouping Type: group [Inclusive Regex]: .* [Exclusive Regex]: ----------------------------------- Removed condition(s) from "user_group" ----------------------------------- Automember Rule: user_group ------------------------------ Number of conditions removed 1 ------------------------------
15.8. Applying automember rules to existing entries using IdM CLI
Automember rules apply automatically to user and host entries created after the rules were added. They are not applied retroactively to entries that existed before the rules were added.
To apply automember rules to previously added entries, you have to manually rebuild automatic membership. Rebuilding automatic membership re-evaluates all existing automember rules and applies them either to all user or hosts entries, or to specific entries.
Rebuilding automatic membership does not remove user or host entries from groups, even if the entries no longer match the group’s inclusive conditions. To remove them manually, see Removing a member from a user group using IdM CLI or Removing IdM host group members using the CLI.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
Procedure
To rebuild automatic membership, enter the
ipa automember-rebuild
command. Use the following options to specify the entries to target:To rebuild automatic membership for all users, use the
--type=group
option:$ ipa automember-rebuild --type=group -------------------------------------------------------- Automember rebuild task finished. Processed (9) entries. --------------------------------------------------------
-
To rebuild automatic membership for all hosts, use the
--type=hostgroup
option. To rebuild automatic membership for a specified user or users, use the
--users=target_user
option:$ ipa automember-rebuild --users=target_user1 --users=target_user2 -------------------------------------------------------- Automember rebuild task finished. Processed (2) entries. --------------------------------------------------------
-
To rebuild automatic membership for a specified host or hosts, use the
--hosts=client.idm.example.com
option.
15.9. Configuring a default automember group using IdM CLI
When you configure a default automember group, new user or host entries that do not match any automember rule are automatically added to this default group.
Prerequisites
- You must be logged in as the administrator. For details, see Using kinit to log in to IdM manually.
- The target group you want to set as default exists in IdM.
Procedure
-
Enter the
ipa automember-default-group-set
command to configure a default automember group. When prompted, specify:
- Default (fallback) Group, which specifies the target group name.
Grouping Type, which specifies whether the target is a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.
For example:
$ ipa automember-default-group-set Default (fallback) Group: default_user_group Grouping Type: group --------------------------------------------------- Set default (fallback) group for automember "default_user_group" --------------------------------------------------- Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
NoteTo remove the current default automember group, enter the
ipa automember-default-group-remove
command.
Verification steps
To verify that the group is set correctly, enter the
ipa automember-default-group-show
command. The command displays the current default automember group. For example:$ ipa automember-default-group-show Grouping Type: group Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
Chapter 16. Automating group membership using IdM Web UI
Using automatic group membership enables you to assign users and hosts to groups automatically based on their attributes. For example, you can:
- Divide employees' user entries into groups based on the employees' manager, location, or any other attribute.
- Divide hosts based on their class, location, or any other attribute.
- Add all users or all hosts to a single global group.
This chapter covers the following topics:
- Benefits of automatic group membership
- Automember rules
- Adding an automember rule using IdM Web UI
- Adding a condition to an automember rule using IdM Web UI
- Viewing existing automember rules and conditions using IdM Web UI
- Deleting an automember rule using IdM Web UI
- Removing a condition from an automember rule using IdM Web UI
- Applying automember rules to existing entries using IdM Web UI
- Configuring a default user group using IdM Web UI
- Configuring a default host group using IdM Web UI
16.1. Benefits of automatic group membership
Using automatic membership for users allows you to:
Reduce the overhead of manually managing group memberships
You no longer have to assign every user and host to groups manually.
Improve consistency in user and host management
Users and hosts are assigned to groups based on strictly defined and automatically evaluated criteria.
Simplify the management of group-based settings
Various settings are defined for groups and then applied to individual group members, for example
sudo
rules, automount, or access control. Adding users and hosts to groups automatically makes managing these settings easier.
16.2. Automember rules
When configuring automatic group membership, the administrator defines automember rules. An automember rule applies to a specific user or host target group. It cannot apply to more than one group at a time.
After creating a rule, the administrator adds conditions to it. These specify which users or hosts get included or excluded from the target group:
Inclusive conditions
When a user or host entry meets an inclusive condition, it will be included in the target group.
Exclusive conditions
When a user or host entry meets an exclusive condition, it will not be included in the target group.
The conditions are specified as regular expressions in the Perl-compatible regular expressions (PCRE) format. For more information on PCRE, see the pcresyntax(3) man page.
IdM evaluates exclusive conditions before inclusive conditions. In case of a conflict, exclusive conditions take precedence over inclusive conditions.
An automember rule applies to every entry created in the future. These entries will be automatically added to the specified target group. If an entry meets the conditions specified in multiple automember rules, it will be added to all the corresponding groups.
Existing entries are not affected by the new rule. If you want to change existing entries, see Applying automember rules to existing entries using IdM Web UI.
16.3. Adding an automember rule using IdM Web UI
This section describes adding an automember rule using the IdM Web UI. For information about automember rules, see Automember rules.
Existing entries are not affected by the new rule. If you want to change existing entries, see Applying automember rules to existing entries using IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group. - The target group of the new rule exists in IdM.
Procedure
- Click Identity → Automember, and select either User group rules or Host group rules.
- Click Add.
In the Automember rule field, select the group to which the rule will apply. This is the target group name.
- Click Add to confirm.
- Optional: You can add conditions to the new rule using the procedure described in Adding a condition to an automember rule using IdM Web UI.
16.4. Adding a condition to an automember rule using IdM Web UI
This section describes how to add a condition to an automember rule using the IdM Web UI. For information about automember rules, see Automember rules.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group. - The target rule exists in IdM.
Procedure
- Click Identity → Automember, and select either User group rules or Host group rules.
- Click on the rule to which you want to add a condition.
In the Inclusive or Exclusive sections, click Add.
- In the Attribute field, select the required attribute, for example uid.
- In the Expression field, define a regular expression.
Click Add.
For example, the following condition targets all users with any value (.*) in their user ID (uid) attribute.
16.5. Viewing existing automember rules and conditions using IdM Web UI
This section describes how to view existing automember rules and conditions using the IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group.
Procedure
- Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.
Optional: Click on a rule to see the conditions for that rule in the Inclusive or Exclusive sections.
16.6. Deleting an automember rule using IdM Web UI
This section describes how to delete an automember rule using the IdM Web UI.
Deleting an automember rule also deletes all conditions associated with the rule. To remove only specific conditions from a rule, see Removing a condition from an automember rule using IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group.
Procedure
- Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.
- Select the check box next to the rule you want to remove.
Click Delete.
- Click Delete to confirm.
16.7. Removing a condition from an automember rule using IdM Web UI
This section describes how to remove a specific condition from an automember rule using the IdM Web UI.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group.
Procedure
- Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.
- Click on a rule to see the conditions for that rule in the Inclusive or Exclusive sections.
- Select the check box next to the conditions you want to remove.
Click Delete.
- Click Delete to confirm.
16.8. Applying automember rules to existing entries using IdM Web UI
Automember rules apply automatically to user and host entries created after the rules were added. They are not applied retroactively to entries that existed before the rules were added.
To apply automember rules to previously added entries, you have to manually rebuild automatic membership. Rebuilding automatic membership re-evaluates all existing automember rules and applies them either to all user or hosts entries, or to specific entries.
Rebuilding automatic membership does not remove user or host entries from groups, even if the entries no longer match the group’s inclusive conditions. To remove them manually, see Removing a member from a user group using IdM Web UI or Removing host group members in the IdM Web UI.
16.8.1. Rebuilding automatic membership for all users or hosts
This section describes how to rebuild automatic membership for all user or host entries.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group.
Procedure
- Select Identity → Users or Hosts.
Click Actions → Rebuild auto membership.
16.8.2. Rebuilding automatic membership for a single user or host only
This section describes how to rebuild automatic membership for a specific user or host entry.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group.
Procedure
- Select Identity → Users or Hosts.
- Click on the required user or host name.
Click Actions → Rebuild auto membership.
16.9. Configuring a default user group using IdM Web UI
When you configure a default user group, new user entries that do not match any automember rule are automatically added to this default group.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group. - The target user group you want to set as default exists in IdM.
Procedure
- Click Identity → Automember, and select User group rules.
In the Default user group field, select the group you want to set as the default user group.
16.10. Configuring a default host group using IdM Web UI
When you configure a default host group, new host entries that do not match any automember rule are automatically added to this default group.
Prerequisites
- You are logged in to the IdM Web UI.
-
You must be a member of the
admins
group. - The target host group you want to set as default exists in IdM.
Procedure
- Click Identity → Automember, and select Host group rules.
In the Default host group field, select the group you want to set as the default host group.
Chapter 17. Managing self-service rules in IdM using the CLI
This chapter introduces self-service rules in Identity Management (IdM) and describes how to create and edit self-service access rules in the command-line interface (CLI).
17.1. Self-service access control in IdM
Self-service access control rules define which operations an IdM entity can perform on its IdM Directory Server entry: for example, IdM users have the ability to update their own passwords.
This method of control allows an authenticated IdM entity to edit specific attributes within its LDAP entry, but does not allow add
or delete
operations on the entire entry.
Exercise care when working with self-service access control rules: configuring access control rules improperly can inadvertently elevate an entity’s privileges.
17.2. Creating self-service rules using the CLI
This procedure describes creating self-service access rules in IdM using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
To add a self-service rule, use the
ipa selfservice-add
command and specify the following two options:--permissions
- sets the read and write permissions the Access Control Instruction (ACI) grants.
--attrs
- sets the complete list of attributes to which this ACI grants permission.
For example, to create a self-service rule allowing users to modify their own name details:
$ 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 Permissions: write Attributes: givenname, displayname, title, initials
17.3. Editing self-service rules using the CLI
This procedure describes editing self-service access rules in IdM using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
-
Optional: Display existing self-service rules with the
ipa selfservice-find
command. -
Optional: Display details for the self-service rule you want to modify with the
ipa selfservice-show
command. -
Use the
ipa selfservice-mod
command to edit a self-service rule.
For example:
$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname -------------------------------------------------------------- Modified selfservice "Users can manage their own name details" -------------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
Using the ipa selfservice-mod
command overwrites the previously defined permissions and attributes, so always include the complete list of existing permissions and attributes along with any new ones you want to define.
Verification steps
-
Use the
ipa selfservice-show
command to display the self-service rule you edited.
$ ipa selfservice-show "Users can manage their own name details" -------------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
17.4. Deleting self-service rules using the CLI
This procedure describes deleting self-service access rules in IdM using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
-
Use the
ipa selfservice-del
command to delete a self-service rule.
For example:
$ ipa selfservice-del "Users can manage their own name details" ----------------------------------------------------------- Deleted selfservice "Users can manage their own name details" -----------------------------------------------------------
Verification steps
-
Use the
ipa selfservice-find
command to display all self-service rules. The rule you just deleted should be missing.
Chapter 18. Managing self-service rules using the IdM Web UI
This chapter introduces self-service rules in Identity Management (IdM) and describes how to create and edit self-service access rules in the web interface (IdM Web UI).
18.1. Self-service access control in IdM
Self-service access control rules define which operations an IdM entity can perform on its IdM Directory Server entry: for example, IdM users have the ability to update their own passwords.
This method of control allows an authenticated IdM entity to edit specific attributes within its LDAP entry, but does not allow add
or delete
operations on the entire entry.
Exercise care when working with self-service access control rules: configuring access control rules improperly can inadvertently elevate an entity’s privileges.
18.2. Creating self-service rules using the IdM Web UI
This procedure describes how to create self-service access rules in IdM using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Open the Role-Based Access Control sub-menu in the IPA Server tab and select Self Service Permissions.
Click Add at the top-right of the list of the self-service access rules:
The Add Self Service Permission window opens. Enter the name of the new self-service rule in the Self-service name field. Spaces are allowed:
- Select the check boxes next to the attributes you want users to be able to edit.
Optional: If an attribute you would like to provide access to is not listed, you can add a listing for it:
- Click the Add button.
- Enter the attribute name in the Attribute text field of the following Add Custom Attribute window.
- Click the OK button to add the attribute
- Verify that the new attribute is selected
-
Click the Add button at the bottom of the form to save the new self-service rule.
Alternatively, you can save and continue editing the self-service rule by clicking the Add and Edit button, or save and add further rules by clicking the Add and Add another button.
18.3. Editing self-service rules using the IdM Web UI
This procedure describes how to edit self-service access rules in IdM using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Open the Role-Based Access Control sub-menu in the IPA Server tab and select Self Service Permissions.
Click on the name of the self-service rule you want to modify.
- The edit page only allows you to edit the list of attributes to you want to add or remove to the self-service rule. Select or deselect the appropriate check boxes.
- Click the Save button to save your changes to the self-service rule.
18.4. Deleting self-service rules using the IdM Web UI
This procedure describes how to delete self-service access rules in IdM using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Open the Role-Based Access Control sub-menu in the IPA Server tab and select Self Service Permissions.
Select the check box next to the rule you want to delete, then click on the Delete button on the right of the list.
- A dialog opens, click on Delete to confirm.
Chapter 19. Delegating permissions over users using IdM CLI
Delegation is one of the access control methods in IdM, along with self-service rules and role-based access control.
Delegation is similar to roles in that one group of users is assigned permission to manage the entries for another group of users. However, the delegated authority 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. Also, the groups in delegated authority are existing IdM user groups instead of roles specifically created for access controls.
This chapter covers the following topics:
19.1. Delegation rules
You can delegate permissions over users by creating delegation rules.
Delegation rules allow a specific user group to perform write (edit) operations on specific attributes for users in another user group. 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.
Delegation rules use existing user groups in IdM. You can use delegation to, for example, allow the managers
user group to manage selected attributes of users in the employees
user group.
19.2. Creating a delegation rule using IdM CLI
This section describes how to create a delegation rule using the IdM CLI.
Prerequisites
-
You are logged in as a member of the
admins
group.
Procedure
Enter the
ipa delegation-add
command. Specify the following options:-
--group
: the group who is being granted permissions to the entries of users in the user group. -
--membergroup
: the group whose entries can be edited by members of the delegation group. -
--permissions
: whether users will have the right to view the given attributes (read) and add or change the given attributes (write). If you do not specify permissions, only the write permission will be added. -
--attrs
: the attributes which users in the member group are allowed to view or edit.
For example:
-
$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
Delegation name: basic manager attributes
Permissions: read, write
Attributes: businesscategory, departmentnumber, employeetype, employeenumber
Member user group: employees
User group: managers
19.3. Viewing existing delegation rules using IdM CLI
This section describes how to view existing delegation rules using the IdM CLI.
Prerequisites
-
You are logged in as a member of the
admins
group.
Procedure
-
Enter the
ipa delegation-find
command:
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
Delegation name: basic manager attributes
Permissions: read, write
Attributes: businesscategory, departmentnumber, employeenumber, employeetype
Member user group: employees
User group: managers
----------------------------
Number of entries returned 1
----------------------------
19.4. Modifying a delegation rule using IdM CLI
This section describes how to modify an existing delegation rule using the IdM CLI.
The --attrs
option overwrites whatever the previous list of supported attributes was, so always include the complete list of attributes along with any new attributes. This also applies to the --permissions
option.
Prerequisites
-
You are logged in as a member of the
admins
group.
Procedure
Enter the
ipa delegation-mod
command with the desired changes. For example, to add thedisplayname
attribute to thebasic manager attributes
example rule:$ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname ---------------------------------------------- Modified delegation "basic manager attributes" ---------------------------------------------- Delegation name: basic manager attributes Permissions: read, write Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname Member user group: employees User group: managers
19.5. Deleting a delegation rule using IdM CLI
This section describes how to delete an existing delegation rule using the IdM CLI.
Prerequisites
-
You are logged in as a member of the
admins
group.
Procedure
-
Enter the
ipa delegation-del
command. When prompted, enter the name of the delegation rule you want to delete:
$ ipa delegation-del Delegation name: basic manager attributes --------------------------------------------- Deleted delegation "basic manager attributes" ---------------------------------------------
Chapter 20. Delegating permissions over users using IdM WebUI
Delegation is one of the access control methods in IdM, along with self-service rules and role-based access control.
Delegation is similar to roles in that one group of users is assigned permission to manage the entries for another group of users. However, the delegated authority 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. Also, the groups in delegated authority are existing IdM user groups instead of roles specifically created for access controls.
This chapter covers the following topics:
20.1. Delegation rules
You can delegate permissions over users by creating delegation rules.
Delegation rules allow a specific user group to perform write (edit) operations on specific attributes for users in another user group. 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.
Delegation rules use existing user groups in IdM. You can use delegation to, for example, allow the managers
user group to manage selected attributes of users in the employees
user group.
20.2. Creating a delegation rule using IdM WebUI
This section describes how to create a delegation rule using the IdM WebUI.
Prerequisites
-
You are logged in to the IdM Web UI as a member of the
admins
group.
Procedure
- From the IPA Server menu, click Role-Based Access Control → Delegations.
Click Add.
In the Add delegation window, do the following:
- Name the new delegation rule.
- Set the permissions by selecting the check boxes that indicate whether users will have the right to view the given attributes (read) and add or change the given attributes (write).
- In the User group drop-down menu, select the group who is being granted permissions to view or edit the entries of users in the member group.
- In the Member user group drop-down menu, select the group whose entries can be edited by members of the delegation group.
In the attributes box, select the check boxes by the attributes to which you want to grant permissions.
- Click the Add button to save the new delegation rule.
20.3. Viewing existing delegation rules using IdM WebUI
This section describes how to view existing delegation rules using the IdM WebUI.
Prerequisites
-
You are logged in to the IdM Web UI as a member of the
admins
group.
Procedure
From the IPA Server menu, click Role-Based Access Control → Delegations.
20.4. Modifying a delegation rule using IdM WebUI
This section describes how to modify an existing delegation rule using the IdM WebUI.
Prerequisites
-
You are logged in to the IdM Web UI as a member of the
admins
group.
Procedure
From the IPA Server menu, click Role-Based Access Control → Delegations.
- Click on the rule you want to modify.
Make the desired changes:
- Change the name of the rule.
- Change granted permissions by selecting the check boxes that indicate whether users will have the right to view the given attributes (read) and add or change the given attributes (write).
- In the User group drop-down menu, select the group who is being granted permissions to view or edit the entries of users in the member group.
- In the Member user group drop-down menu, select the group whose entries can be edited by members of the delegation group.
In the attributes box, select the check boxes by the attributes to which you want to grant permissions. To remove permissions to an attribute, uncheck the relevant check box.
- Click the Save button to save the changes.
20.5. Deleting a delegation rule using IdM WebUI
This section describes how to delete an existing delegation rule using the IdM WebUI.
Prerequisites
-
You are logged in to the IdM Web UI as a member of the
admins
group.
Procedure
- From the IPA Server menu, click Role-Based Access Control → Delegations.
- Select the check box next to the rule you want to remove.
Click Delete.
- Click Delete to confirm.
Chapter 21. Managing role-based access controls in IdM using the CLI
This chapter introduces role-based access control in Identity Management (IdM) and describes the following operations in the command-line interface (CLI):
21.1. Role-based access control in IdM
Role-based access control (RBAC) in IdM grants a very different kind of authority to users compared to self-service and delegation access controls.
Role-based access control is composed of three parts:
- Permissions grant the right to perform a specific task such as adding or deleting users, modifying a group, enabling read-access, etc.
- Privileges combine permissions, for example all the permissions needed to add a new user.
- Roles grant a set of privileges to users, user groups, hosts or host groups.
21.1.1. Permissions in IdM
Permissions are the lowest level unit of role-based access control, they define operations together with the LDAP entries to which those operations apply. Comparable to building blocks, permissions can be assigned to as many privileges as needed.
One or more rights define what operations are allowed:
-
write
-
read
-
search
-
compare
-
add
-
delete
-
all
These operations apply to three basic targets:
-
subtree
: a domain name (DN); the subtree under this DN -
target filter
: an LDAP filter -
target
: DN with possible wildcards to specify entries
Additionally, the following convenience options set the corresponding attribute(s):
-
type
: a type of object (user, group, etc); setssubtree
andtarget filter
-
memberof
: members of a group; sets atarget filter
-
targetgroup
: grants access to modify a specific group (such as granting the rights to manage group membership); sets atarget
With IdM permissions, you can control which users have access to which objects and even which attributes of these objects. IdM enables you to allow or block 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.
For example, the flexibility of this approach to permissions is useful for an administrator who 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.
A permission cannot contain other permissions.
21.1.2. Default managed permissions
Managed permissions are permissions that come by default with IdM. They behave like other permissions created by the user, with the following differences:
- You cannot delete them or modify their name, location, and target attributes.
They have three sets of attributes:
- Default attributes, the user cannot modify them, as they are managed by IdM
- Included attributes, which are additional attributes added by the user
- Excluded attributes, which are attributes removed by the user
A managed permission applies to all attributes that appear in the default and included attribute sets but not in the excluded set.
While you cannot delete a managed permission, setting its bind type to permission and removing the managed permission from all privileges effectively disables it.
Names of all managed permissions start with System:
, for example System: Add Sudo rule
or System: Modify Services
. Earlier versions of IdM used a different scheme for default permissions. For example, the user could not delete them and was only able to assign them to privileges. Most of these default permissions have been turned into managed permissions, however, the following permissions still use the previous scheme:
- Add Automember Rebuild Membership Task
- Add Configuration Sub-Entries
- Add Replication Agreements
- Certificate Remove Hold
- Get Certificates status from the CA
- Read DNA Range
- Modify DNA Range
- Read PassSync Managers Configuration
- Modify PassSync Managers Configuration
- Read Replication Agreements
- Modify Replication Agreements
- Remove Replication Agreements
- Read LDBM Database Configuration
- Request Certificate
- Request Certificate ignoring CA ACLs
- Request Certificates from a different host
- Retrieve Certificates from the CA
- Revoke Certificate
- Write IPA Configuration
If you attempt to modify a managed permission from the command line, the system does not allow you to change the attributes that you cannot modify, the command fails. If you attempt to modify a managed permission from the Web UI, the attributes that you cannot modify are disabled.
21.1.3. Privileges in IdM
A privilege is a group of permissions applicable to a role.
While a permission provides the rights to do a single operation, there are certain IdM tasks that require multiple permissions to succeed. Therefore, a privilege combines the different permissions required to perform a specific task.
For example, adding a user requires the following permissions:
- Creating a new user entry
- Resetting a user password
- Adding the new user to the default IPA users group
Combining these three low-level tasks into a higher level task in the form of a privilege named Add User makes it easier to manage roles. Apart from users and user groups, privileges are also assigned to hosts and host groups, as well as network services. This practice permits a fine-grained control of operations by a set of users on a set of hosts using specific network services.
A privilege may not contain other privileges.
21.1.4. Roles in IdM
A role is a list of privileges that users specified for the role possess.
In effect, permissions grant the ability to perform given low-level tasks (create a user entry, add an entry to a group, etc.), privileges combine one or more of these permissions needed for a higher-level task (such as creating a new user in a given group). Roles gather privileges together as needed: for example, a User Administrator role would be able to add, modify, and delete users.
Roles are used to classify permitted actions. They are not used as a tool to implement privilege separation or to protect from privilege escalation.
Roles can not contain other roles.
21.1.5. Predefined roles in Identity Management
Red Hat Identity Management provides the following range of pre-defined roles:
Table 21.1. Predefined Roles in Identity Management
Role | Privilege | Description |
---|---|---|
Helpdesk | Modify Users and Reset passwords, Modify Group membership | Responsible for performing simple user administration tasks |
IT Security Specialist | Netgroups Administrators, HBAC Administrator, Sudo Administrator | Responsible for managing security policy such as host-based access controls, sudo rules |
IT Specialist | Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators | Responsible for managing hosts |
Security Architect | Delegation Administrator, Replication Administrators, Write IPA Configuration, Password Policy Administrator | Responsible for managing the Identity Management environment, creating trusts, creating replication agreements |
User Administrator | User Administrators, Group Administrators, Stage User Administrators | Responsible for creating users and groups |
21.2. Managing IdM permissions in the CLI
This section describes how to manage Identity Management (IdM) permissions using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
Create new permission entries with the
ipa permission-add
command.
For example, to add a permission named dns admin:$ ipa permission-add "dns admin"
Specify the properties of the permission with the following options:
--bindtype
specifies the bind rule type. This option accepts theall
,anonymous
, andpermission
arguments. Thepermission
bindtype means that only the users who are granted this permission via a role can exercise it.
For example:$ ipa permission-add "dns admin" --bindtype=all
If you do not specify
--bindtype
, thenpermission
is the default value.NoteIt is not possible to add permissions with a non-default bind rule type to privileges. You also cannot set a permission that is already present in a privilege to a non-default bind rule type.
--right
lists the rights granted by the permission, it replaces the deprecated--permissions
option. The available values areadd
,delete
,read
,search
,compare
,write
,all
.You can set multiple attributes by using multiple
--right
options or with a comma-separated list inside curly braces. For example:$ ipa permission-add "dns admin" --right=read --right=write
$ ipa permission-add "dns admin" --right={read,write}
Noteadd
anddelete
are entry-level operations (for example deleting a user, adding a group, etc.) whileread
,search
,compare
andwrite
are more attribute-level: you can write touserCertificate
but not readuserPassword
.--attrs
gives the list of attributes over which the permission is granted.
You can set multiple attributes by using multiple--attrs
options or by listing the options in a comma-separated list inside curly braces. For example:$ ipa permission-add "dns admin" --attrs=description --attrs=automountKey
$ ipa permission-add "dns admin" --attrs={description,automountKey}
The attributes provided with
--attrs
must exist and be allowed attributes for the given object type, otherwise the command fails with schema syntax errors.--type
defines the entry object type to which the permission applies, such as user, host, or service. Each type has its own set of allowed attributes.
For example:$ ipa permission-add "manage service" --right=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
--subtree
gives a subtree entry; the filter then targets every entry beneath this subtree entry. Provide an existing subtree entry;--subtree
does not accept wildcards or non-existent domain names (DNs). Include a DN within the directory.
Because IdM uses a simplified, flat directory tree structure,--subtree
can be used to target some types of entries, like automount locations, which are containers or parent entries for other configuration. For example:$ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --right=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
NoteThe
--type
and--subtree
options are mutually exclusive: you can see the inclusion of filters for--type
as a simplification of--subtree
, intending to make life easier for an admin.--filter
uses an LDAP filter to identify which entries the permission applies to.
IdM automatically checks the validity of the given filter. The filter can be any valid LDAP filter, for example:$ ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --right=write --attrs=description
--memberof
sets the target filter to members of the given group after checking that the group exists. For example, to let the users with this permission modify the login shell of members of the engineers group:$ ipa permission-add ManageShell --right="write" --type=user --attr=loginshell --memberof=engineers
--targetgroup
sets target to the specified user group after checking that the group exists. For example, to let those with the permission write the member attribute in the engineers group (so they can add or remove members):$ ipa permission-add ManageMembers --right="write" --subtree=cn=groups,cn=accounts,dc=example,dc=test --attr=member --targetgroup=engineers
Optionally, you can specify a target domain name (DN):
-
--target
specifies the DN to apply the permission to. Wildcards are accepted. -
--targetto
specifies the DN subtree where an entry can be moved to. -
--targetfrom
specifies the DN subtree from where an entry can be moved.
-
21.3. Command options for existing permissions
Use the following variants to modify existing permissions as needed:
-
To edit existing permissions, use the
ipa permission-mod
command. You can use the same command options as for adding permissions. -
To find existing permissions, use the
ipa permission-find
command. You can use the same command options as for adding permissions. To view a specific permission, use the
ipa permission-show
command.
The--raw
argument shows the raw 389-ds ACI that is generated. For example:$ ipa permission-show <permission> --raw
-
The
ipa permission-del
command deletes a permission completely.
Additional resources
For further details about the ipa permission
commands, refer to the ipa man page and the ipa help
command.
21.4. Managing IdM privileges in the CLI
This section describes how to manage Identity Management (IdM) privileges using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
- Existing permissions. For details about permissions, see Managing IdM permissions in the CLI.
Procedure
Add privilege entries using the
ipa privilege-add
command
For example, to add a privilege named managing filesystems with a description:$ ipa privilege-add "managing filesystems" --desc="for filesystems"
Assign the required permissions to the privilege group with the
privilege-add-permission
command
For example, to add the permissions named managing automount and managing ftp services to the managing filesystems privilege:$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"
21.5. Command options for existing privileges
Use the following variants to modify existing privileges as needed:
-
To modify existing privileges, use the
ipa privilege-mod
command. -
To find existing privileges, use the
ipa privilege-find
command. -
To view a specific privilege, use the
ipa privilege-show
command. -
The
ipa privilege-remove-permission
command removes one or more permissions from a privilege. -
The
ipa privilege-del
command deletes a privilege completely.
Additional resources
For further details about the ipa privilege
commands, refer to the ipa man page and the ipa help
command.
21.6. Managing IdM roles in the CLI
This section describes how to manage Identity Management (IdM) roles using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
- Existing privileges. For details about privileges, see Managing IdM privileges in the CLI.
Procedure
Add new role entries using the
ipa role-add
command:$ ipa role-add --desc="User Administrator" useradmin ------------------------ Added role "useradmin" ------------------------ Role name: useradmin Description: User Administrator
Add the required privileges to the role using the
ipa role-add-privilege
command:$ ipa role-add-privilege --privileges="user administrators" useradmin Role name: useradmin Description: User Administrator Privileges: user administrators ---------------------------- Number of privileges added 1 ----------------------------
Add the required members to the role using the
ipa role-add-member
command. Allowed member types are: users, groups, hosts and hostgroups.
For example, to add the group named useradmins to the previously created useradmin role:$ ipa role-add-member --groups=useradmins useradmin Role name: useradmin Description: User Administrator Member groups: useradmins Privileges: user administrators ------------------------- Number of members added 1 -------------------------
21.7. Command options for existing roles
Use the following variants to modify existing roles as needed:
-
To modify existing roles, use the
ipa role-mod
command. -
To find existing roles, use the
ipa role-find
command. -
To view a specific role, use the
ipa role-show
command. -
To remove a member from the role, use the
ipa role-remove-member
command. -
The
ipa role-remove-privilege
command removes one or more privileges from a role. -
The
ipa role-del
command deletes a role completely.
Additional resources
For further details about the ipa role
commands, refer to the ipa man page and the ipa help
command.
Chapter 22. Managing role-based access controls using the IdM Web UI
This chapter introduces role-based access control in Identity Management (IdM) and describes the following operations in the web interface (Web UI):
22.1. Role-based access control in IdM
Role-based access control (RBAC) in IdM grants a very different kind of authority to users compared to self-service and delegation access controls.
Role-based access control is composed of three parts:
- Permissions grant the right to perform a specific task such as adding or deleting users, modifying a group, enabling read-access, etc.
- Privileges combine permissions, for example all the permissions needed to add a new user.
- Roles grant a set of privileges to users, user groups, hosts or host groups.
22.1.1. Permissions in IdM
Permissions are the lowest level unit of role-based access control, they define operations together with the LDAP entries to which those operations apply. Comparable to building blocks, permissions can be assigned to as many privileges as needed.
One or more rights define what operations are allowed:
-
write
-
read
-
search
-
compare
-
add
-
delete
-
all
These operations apply to three basic targets:
-
subtree
: a domain name (DN); the subtree under this DN -
target filter
: an LDAP filter -
target
: DN with possible wildcards to specify entries
Additionally, the following convenience options set the corresponding attribute(s):
-
type
: a type of object (user, group, etc); setssubtree
andtarget filter
-
memberof
: members of a group; sets atarget filter
-
targetgroup
: grants access to modify a specific group (such as granting the rights to manage group membership); sets atarget
With IdM permissions, you can control which users have access to which objects and even which attributes of these objects. IdM enables you to allow or block 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.
For example, the flexibility of this approach to permissions is useful for an administrator who 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.
A permission cannot contain other permissions.
22.1.2. Default managed permissions
Managed permissions are permissions that come by default with IdM. They behave like other permissions created by the user, with the following differences:
- You cannot delete them or modify their name, location, and target attributes.
They have three sets of attributes:
- Default attributes, the user cannot modify them, as they are managed by IdM
- Included attributes, which are additional attributes added by the user
- Excluded attributes, which are attributes removed by the user
A managed permission applies to all attributes that appear in the default and included attribute sets but not in the excluded set.
While you cannot delete a managed permission, setting its bind type to permission and removing the managed permission from all privileges effectively disables it.
Names of all managed permissions start with System:
, for example System: Add Sudo rule
or System: Modify Services
. Earlier versions of IdM used a different scheme for default permissions. For example, the user could not delete them and was only able to assign them to privileges. Most of these default permissions have been turned into managed permissions, however, the following permissions still use the previous scheme:
- Add Automember Rebuild Membership Task
- Add Configuration Sub-Entries
- Add Replication Agreements
- Certificate Remove Hold
- Get Certificates status from the CA
- Read DNA Range
- Modify DNA Range
- Read PassSync Managers Configuration
- Modify PassSync Managers Configuration
- Read Replication Agreements
- Modify Replication Agreements
- Remove Replication Agreements
- Read LDBM Database Configuration
- Request Certificate
- Request Certificate ignoring CA ACLs
- Request Certificates from a different host
- Retrieve Certificates from the CA
- Revoke Certificate
- Write IPA Configuration
If you attempt to modify a managed permission from the command line, the system does not allow you to change the attributes that you cannot modify, the command fails. If you attempt to modify a managed permission from the Web UI, the attributes that you cannot modify are disabled.
22.1.3. Privileges in IdM
A privilege is a group of permissions applicable to a role.
While a permission provides the rights to do a single operation, there are certain IdM tasks that require multiple permissions to succeed. Therefore, a privilege combines the different permissions required to perform a specific task.
For example, adding a user requires the following permissions:
- Creating a new user entry
- Resetting a user password
- Adding the new user to the default IPA users group
Combining these three low-level tasks into a higher level task in the form of a privilege named Add User makes it easier to manage roles. Apart from users and user groups, privileges are also assigned to hosts and host groups, as well as network services. This practice permits a fine-grained control of operations by a set of users on a set of hosts using specific network services.
A privilege may not contain other privileges.
22.1.4. Roles in IdM
A role is a list of privileges that users specified for the role possess.
In effect, permissions grant the ability to perform given low-level tasks (create a user entry, add an entry to a group, etc.), privileges combine one or more of these permissions needed for a higher-level task (such as creating a new user in a given group). Roles gather privileges together as needed: for example, a User Administrator role would be able to add, modify, and delete users.
Roles are used to classify permitted actions. They are not used as a tool to implement privilege separation or to protect from privilege escalation.
Roles can not contain other roles.
22.1.5. Predefined roles in Identity Management
Red Hat Identity Management provides the following range of pre-defined roles:
Table 22.1. Predefined Roles in Identity Management
Role | Privilege | Description |
---|---|---|
Helpdesk | Modify Users and Reset passwords, Modify Group membership | Responsible for performing simple user administration tasks |
IT Security Specialist | Netgroups Administrators, HBAC Administrator, Sudo Administrator | Responsible for managing security policy such as host-based access controls, sudo rules |
IT Specialist | Host Administrators, Host Group Administrators, Service Administrators, Automount Administrators | Responsible for managing hosts |
Security Architect | Delegation Administrator, Replication Administrators, Write IPA Configuration, Password Policy Administrator | Responsible for managing the Identity Management environment, creating trusts, creating replication agreements |
User Administrator | User Administrators, Group Administrators, Stage User Administrators | Responsible for creating users and groups |
22.2. Managing permissions in the IdM Web UI
This section describes how to manage permissions in Identity Management (IdM) using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
To add a new permission, open the Role-Based Access Control sub-menu in the IPA Server tab and select Permissions:
The list of permissions opens: Click the Add button at the top of the list of the permissions:
The Add Permission form opens. Specify the name of the new permission and define its properties accordingly:
Select the appropriate Bind rule type:
- permission is the default permission type, granting access through privileges and roles
- all specifies that the permission applies to all authenticated users
anonymous specifies that the permission applies to all users, including unauthenticated users
NoteIt is not possible to add permissions with a non-default bind rule type to privileges. You also cannot set a permission that is already present in a privilege to a non-default bind rule type.
- Choose the rights to grant with this permisthsion in Granted rights.
Define the method to identify the target entries for the permission:
- Type specifies an entry type, such as user, host, or service. If you choose a value for the Type setting, a list of all possible attributes which will be accessible through this ACI for that entry type appears under Effective Attributes. Defining Type sets Subtree and Target DN to one of the predefined values.
-
Subtree (required) specifies a subtree entry; every entry beneath this subtree entry is then targeted. Provide an existing subtree entry, as Subtree does not accept wildcards or non-existent domain names (DNs). For example:
cn=automount,dc=example,dc=com
-
Extra target filter uses an LDAP filter to identify which entries the permission applies to. The filter can be any valid LDAP filter, for example:
(!(objectclass=posixgroup))
IdM automatically checks the validity of the given filter. If you enter an invalid filter, IdM warns you about this when you attempt to save the permission. -
Target DN specifies the domain name (DN) and accepts wildcards. For example:
uid=*,cn=users,cn=accounts,dc=com
- Member of group sets the target filter to members of the given group. After you specify the filter settings and click Add, IdM validates the filter. If all the permission settings are correct, IdM will perform the search. If some of the permissions settings are incorrect, IdM will display a message informing you about which setting is set incorrectly.
Add attributes to the permission:
- If you set Type, choose the Effective attributes from the list of available ACI attributes.
If you did not use Type, add the attributes manually by writing them into the Effective attributes field. Add a single attribute at a time; to add multiple attributes, click Add to add another input field.
ImportantIf you do not set any attributes for the permission, then the permissions includes all attributes by default.
Finish adding the permissions with the Add buttons at the bottom of the form:
- Click the Add button to save the permission and go back to the list of permissions.
- Alternatively, you can save the permission and continue adding additional permissions in the same form by clicking the Add and Add another button
- The Add and Edit button enables you to save and continue editing the newly created permission.
- Optional. You can also edit the properties of an existing permission by clicking its name from the list of permissions to display the Permission settings page.
Optional. If you need to remove an existing permission, click the Delete button once you ticked the check box next to its name in the list, to display The Remove permissions dialog.
NoteOperations on default managed permissions are restricted: the attributes you cannot modify are disabled in the IdM Web UI and you cannot delete the managed permissions completely.
However, you can effectively disable a managed permission that has a bind type set to permission, by removing the managed permission from all privileges.
For example, to let those with the permission write the member attribute in the engineers group (so they can add or remove members):
22.3. Managing privileges in the IdM WebUI
This section describes how to manage privileges in IdM using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
- Existing permissions. For details about permissions, see Managing permissions in the IdM Web UI.
Procedure
To add a new privilege, open the Role-Based Access Control sub-menu in the IPA Server tab and select Privileges:
The list of privileges opens. Click the Add button at the top of the list of privileges:
The Add Privilege form opens. Enter the name and a description of the privilege:
- Click the Add and Edit button in order to save the new privilege and continue to the privilege configuration page to add permissions.
- Edit the properties of privileges by clicking on the privileges name in the privileges list. The privileges configuration page opens.
The Permissions tab displays a list of permissions included in the selected privilege. Click the Add button at the top of the list to add permissions to the privilege:
Tick the check box next to the name of each permission to add, and use the > button to move the permissions to the Prospective column:
- Confirm by clicking the Add button.
- Optional. If you need to remove permissions, click the Delete button after you ticked the check box next to the relevant permission: the Remove privileges from permissions dialog opens.
- Optional. If you need to delete an existing privilege, click the Delete button after you ticked the check box next to its name in the list: the Remove privileges dialog opens.
22.4. Managing roles in the IdM Web UI
This section describes how to manage roles in Identity Management (IdM) using the web interface (IdM Web UI).
Prerequisites
- Administrator privileges for managing IdM or the User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
- Existing privileges. For details about privileges, see Managing privileges in the IdM Web UI.
Procedure
To add a new role, open the Role-Based Access Control sub-menu in the IPA Server tab and select Roles:
The list of roles opens. Click the Add button at the top of the list of the role-based access control instructions.
The Add Role form opens. Enter the role name and a description:
- Click the Add and Edit button to save the new role and go to the role configuration page to add privileges and users.
- Edit the properties of roles by clicking on the roles name in the role list. The roles configuration page opens.
Add members using the Users, Users Groups, Hosts, Host Groups or Services tabs, by clicking the Add button on top of the relevant list(s).
In the window that opens, select the members on the left and use the > button to move them to the Prospective column.
At the top of the Privileges tab, click Add.
Select the privileges on the left and use the > button to move them to the Prospective column.
- Click the Add button to save.
- Optional. If you need to remove privileges or members from a role, click the Delete button after you ticked the check box next to the name of the entity you want to remove. A dialog opens.
- Optional. If you need to remove an existing role, click the Delete button after you ticked the check box next to its name in the list, to display the Remove roles dialog.
Chapter 23. Using an ID view to override a user attribute value on an IdM client
If an Identity Management (IdM) user would like to override some of their user or group attributes stored in the IdM LDAP server, for example the login name, home directory, certificate used for authentication, or SSH
keys, you as IdM administrator can redefine these values for a specific IdM client, using IdM ID views. For example, you can specify a different home directory for a user on the IdM client that the user most commonly uses for logging in to IdM.
This chapter describes how to redefine a POSIX attribute value associated with an IdM user on a host enrolled into IdM as a client. Specifically, the chapter describes how to redefine the user login name and home directory.
This chapter includes the following sections:
- ID views
- Potential negative impact of ID views on SSSD performance
- Attributes an ID view can override
- Getting help for ID view commands
- Using an ID view to override the login name of an IdM user on a specific host
- Modifying an IdM ID view
- Adding an ID view to override an IdM user home directory on an IdM client
- Applying an ID view to an IdM host group
23.1. ID views
An ID view in Identity Management (IdM) is an IdM client-side view specifying the following information:
- New values for centrally defined POSIX user or group attributes
- The client host or hosts on which the new values apply.
An ID view contains one or more overrides. An override is a specific replacement of a centrally defined POSIX attribute value.
You can only define an ID view for an IdM client centrally on IdM servers. You cannot configure client-side overrides for an IdM client locally.
For example, you can use ID views to achieve the following goals:
-
Define different attribute values for different environments. For example, you can allow the IdM administrator or another IdM user to have different home directories on different IdM clients: you can configure
/home/encrypted/username
to be this user’s home directory on one IdM client and/dropbox/username
on another client. Using ID views in this situation is convenient as alternatively, for example, changingfallback_homedir
,override_homedir
or other home directory variables in the client’s/etc/sssd/sssd.conf
file would affect all users. See Adding an ID view to override an IdM user home directory on an IdM client for an example procedure. - Replace a previously generated attribute value with a different value, such as overriding a user’s UID. This ability can be useful when you want to achieve a system-wide change that would otherwise be difficult to do on the LDAP side, for example make 1009 the UID of an IdM user. IdM ID ranges, which are used to generate an IdM user UID, never start as low as 1000 or even 10000. If a reason exists for an IdM user to impersonate a local user with UID 1009 on all IdM clients, you can use ID views to override the UID of this IdM user that was generated when the user was created in IdM.
You can only apply ID views to IdM clients, not to IdM servers.
Additional resources
- You can also use ID views in environments involving Active Directory (AD). For details, see the ID Views and Migrating Existing Environments to Trust chapter in the Windows integration guide.
- You can also configure ID views for hosts that are not part of a centralized identity management domain. For details, see the SSSD Client-side Views chapter in the System-level authentication guide.
23.2. Potential negative impact of ID views on SSSD performance
When you define an ID view, IdM places the desired override value in the IdM server’s System Security Services Daemon (SSSD) cache. The SSSD running on an IdM client then retrieves the override value from the server cache.
Applying an ID view can have a negative impact on System Security Services Daemon (SSSD) performance, because certain optimizations and ID views cannot run at the same time. For example, ID views prevent SSSD from optimizing the process of looking up groups on the server:
- With ID views, SSSD must check every member on the returned list of group member names if the group name is overridden.
- Without ID views, SSSD can only collect the user names from the member attribute of the group object.
This negative effect becomes most apparent when the SSSD cache is empty or after you clear the cache, which makes all entries invalid.
23.3. Attributes an ID view can override
ID views consist of user and group ID overrides. The overrides define the new POSIX attribute values.
User and group ID overrides can define new values for the following POSIX attributes:
- User attributes
-
Login name (
uid
) -
GECOS entry (
gecos
) -
UID number (
uidNumber
) -
GID number (
gidNumber
) -
Login shell (
loginShell
) -
Home directory (
homeDirectory
) -
SSH public keys (
ipaSshPubkey
) -
Certificate (
userCertificate
)
-
Login name (
- Group attributes
-
Group name (
cn
) -
Group GID number (
gidNumber
)
-
Group name (
23.4. Getting help for ID view commands
You can get help for commands involving Identity Management (IdM) ID views on the IdM command-line interface (CLI).
Prerequisites
- You have obtained a Kerberos ticket for an IdM user.
Procedure
To display all commands used to manage ID views and overrides:
$ ipa help idviews ID Views Manage ID Views IPA allows to override certain properties of users and groups[...] [...] Topic commands: idoverridegroup-add Add a new Group ID override idoverridegroup-del Delete a Group ID override [...]
To display detailed help for a particular command, add the
--help
option to the command:$ ipa idview-add --help Usage: ipa [global-options] idview-add NAME [options] Add a new ID View. Options: -h, --help show this help message and exit --desc=STR Description [...]
23.5. Using an ID view to override the login name of an IdM user on a specific host
This section describes how to create an ID view for a specific Identity Management (IdM) client that overrides a POSIX attribute value associated with a specific IdM user. The procedure uses the example of an ID view that enables an IdM user named idm_user to log in to an IdM client named host1 using the user_1234 login name.
Prerequisites
- You are logged in as a user with the required privileges, for example admin.
Procedure
Create a new ID view. For example, to create an ID view named
example_for_host1
:$ ipa idview-add example_for_host1 --------------------------- Added ID View "example_for_host1" --------------------------- ID View Name: example_for_host1
Add a user override to the example_for_host1 ID view. To override the user login:
-
Enter the
ipa idoverrideuser-add
command - Add the name of the ID view
- Add the user name, also called the anchor
Add the
--login
option:$ ipa idoverrideuser-add example_for_host1 idm_user --login=user_1234 ----------------------------- Added User ID override "idm_user" ----------------------------- Anchor to override: idm_user User login: user_1234
For a list of the available options, run ipa idoverrideuser-add --help.
NoteThe
ipa idoverrideuser-add --certificate
command replaces all existing certificates for the account in the specified ID view. To append an additional certificate, use theipa idoverrideuser-add-cert
command instead:$ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
-
Enter the
-
Optional: Using the
ipa idoverrideuser-mod
command, you can specify new attribute values for an existing user override. Apply
example_for_host1
to thehost1.idm.example.com
host:$ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com ----------------------------- Applied ID View "example_for_host1" ----------------------------- hosts: host1.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
NoteThe
ipa idview-apply
command also accepts the--hostgroups
option. The option applies the ID view to hosts that belong to the specified host group, but does not associate the ID view with the host group itself. Instead, the--hostgroups
option expands the members of the specified host group and applies the--hosts
option individually to every one of them.This means that if a host is added to the host group in the future, the ID view does not apply to the new host.
To apply the new configuration to the host1.idm.example.com system immediately:
SSH to the system as root:
$ ssh root@host1 Password:
Clear the SSSD cache:
root@host1 ~]# sss_cache -E
- Restart the SSSD daemon:
root@host1 ~]# systemctl restart sssd
Verification steps
If you have the credentials of user_1234, you can use them to log in to IdM on host1:
SSH to host1 using user_1234 as the login name:
[root@r8server ~]# ssh user_1234@host1.idm.example.com Password: Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [user_1234@host1 ~]$
Display the working directory:
[user_1234@host1 ~]$ pwd /home/idm_user/
Alternatively, if you have root credentials on host1, you can use them to check the output of the
id
command for idm_user and user_1234:[root@host1 ~]# id idm_user uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user) [root@host1 ~]# user_1234 uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
23.6. Modifying an IdM ID view
An ID view in Identity Management (IdM) overrides a POSIX attribute value associated with a specific IdM user. This section describes how to modify an existing ID view. Specifically, it describes how to modify an ID view to enable the user named idm_user to use the /home/user_1234/
directory as the user home directory instead of /home/idm_user/
on the host1.idm.example.com IdM client.
Prerequisites
- You have root access to host1.idm.example.com.
- You are logged in as a user with the required privileges, for example admin.
- You have an ID view configured for idm_user that applies to the host1 IdM client.
Procedure
As root, create the directory that you want idm_user to use on host1.idm.example.com as the user home directory:
[root@host1 /]# mkdir /home/user_1234/
Change the ownership of the directory:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
Display the ID view, including the hosts to which the ID view is currently applied. To display the ID view named
example_for_host1
:$ ipa idview-show example_for_host1 --all dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_host1 User object override: idm_user Hosts the view applies to: host1.idm.example.com objectclass: ipaIDView, top, nsContainer
The output shows that the ID view currently applies to host1.idm.example.com.
Modify the user override of the example_for_host1 ID view. To override the user home directory:
-
Enter the
ipa idoverrideuser-add
command - Add the name of the ID view
- Add the user name, also called the anchor
Add the
--homedir
option:$ ipa idoverrideuser-mod example_for_host1 idm_user --homedir=/home/user_1234 ----------------------------- Modified an User ID override "idm_user" ----------------------------- Anchor to override: idm_user User login: user_1234 Home directory: /home/user_1234/
For a list of the available options, run
ipa idoverrideuser-mod --help
.-
Enter the
To apply the new configuration to the host1.idm.example.com system immediately:
SSH to the system as root:
$ ssh root@host1 Password:
Clear the SSSD cache:
root@host1 ~]# sss_cache -E
- Restart the SSSD daemon:
root@host1 ~]# systemctl restart sssd
Verification steps
SSH
to host1 as idm_user:[root@r8server ~]# ssh idm_user@host1.idm.example.com Password: Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [user_1234@host1 ~]$
Print the working directory:
[user_1234@host1 ~]$ pwd /home/user_1234/
23.7. Adding an ID view to override an IdM user home directory on an IdM client
An ID view in Identity Management (IdM) overrides a POSIX attribute value associated with a specific IdM user. This section describes how to create an ID view that applies to idm_user on an IdM client named host1 to enable the user to use the /home/user_1234/
directory as the user home directory instead of /home/idm_user/
.
Prerequisites
- You have root access to host1.idm.example.com.
- You are logged in as a user with the required privileges, for example admin.
Procedure
As root, create the directory that you want idm_user to use on host1.idm.example.com as the user home directory:
[root@host1 /]# mkdir /home/user_1234/
Change the ownership of the directory:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
Create an ID view. For example, to create an ID view named example_for_host1:
$ ipa idview-add example_for_host1 --------------------------- Added ID View "example_for_host1" --------------------------- ID View Name: example_for_host1
Add a user override to the example_for_host1 ID view. To override the user home directory:
-
Enter the
ipa idoverrideuser-add
command - Add the name of the ID view
- Add the user name, also called the anchor
-
Add the
--homedir
option:
$ ipa idoverrideuser-add example_for_host1 idm_user --homedir=/home/user_1234 ----------------------------- Added User ID override "idm_user" ----------------------------- Anchor to override: idm_user Home directory: /home/user_1234/
-
Enter the
Apply
example_for_host1
to thehost1.idm.example.com
host:$ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com ----------------------------- Applied ID View "example_for_host1" ----------------------------- hosts: host1.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
NoteThe
ipa idview-apply
command also accepts the--hostgroups
option. The option applies the ID view to hosts that belong to the specified host group, but does not associate the ID view with the host group itself. Instead, the--hostgroups
option expands the members of the specified host group and applies the--hosts
option individually to every one of them.This means that if a host is added to the host group in the future, the ID view does not apply to the new host.
To apply the new configuration to the host1.idm.example.com system immediately:
SSH to the system as root:
$ ssh root@host1 Password:
Clear the SSSD cache:
root@host1 ~]# sss_cache -E
- Restart the SSSD daemon:
root@host1 ~]# systemctl restart sssd
Verification steps
SSH
to host1 as idm_user:[root@r8server ~]# ssh idm_user@host1.idm.example.com Password: Activate the web console with: systemctl enable --now cockpit.socket Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229 [idm_user@host1 /]$
Print the working directory:
[idm_user@host1 /]$ pwd /home/user_1234/
23.8. Applying an ID view to an IdM host group
The ipa idview-apply
command accepts the --hostgroups
option. However, the option acts as a one-time operation that applies the ID view to hosts that currently belong to the specified host group, but does not dynamically associate the ID view with the host group itself. The --hostgroups
option expands the members of the specified host group and applies the --hosts
option individually to every one of them.
If you add a new host to the host group later, you must apply the ID view to the new host manually, using the ipa idview-apply
command with the --hosts
option.
Similarly, if you remove a host from a host group, the ID view is still assigned to the host after the removal. To unapply the ID view from the removed host, you must run the ipa idview-unapply id_view_name --hosts=name_of_the_removed_host
command.
This section describes how to achieve the following goals:
- How to create a host group and add hosts to it.
- How to apply an ID view to the host group.
- How to add a new host to the host group and apply the ID view to the new host.
Prerequisites
- Ensure that the ID view you want to apply to the host group exists in IdM. For example, to create an ID view to override an IdM user login name on a specific IdM client, see Using an ID view to override the login name of an IdM user on a specific host.
Procedure
Create a host group and add hosts to it:
Create a host group. For example, to create a host group named baltimore:
[root@master ~]# ipa hostgroup-add --desc="Baltimore hosts" baltimore --------------------------- Added hostgroup "baltimore" --------------------------- Host-group: baltimore Description: Baltimore hosts
Add hosts to the host group. For example, to add the host102 and host103 to the baltimore host group:
[root@master ~]# ipa hostgroup-add-member --hosts={host102,host103} baltimore Host-group: baltimore Description: Baltimore hosts Member hosts: host102.idm.example.com, host103.idm.example.com ------------------------- Number of members added 2 -------------------------
Apply an ID view to the hosts in the host group. For example, to apply the example_for_host1 ID view to the baltimore host group:
[root@master ~]# ipa idview-apply --hostgroups=baltimore ID View Name: example_for_host1 ----------------------------------------- Applied ID View "example_for_host1" ----------------------------------------- hosts: host102.idm.example.com, host103.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 2 ---------------------------------------------
Add a new host to the host group and apply the ID view to the new host:
Add a new host to the host group. For example, to add the somehost.idm.example.com host to the baltimore host group:
[root@master ~]# ipa hostgroup-add-member --hosts=somehost.idm.example.com baltimore Host-group: baltimore Description: Baltimore hosts Member hosts: host102.idm.example.com, host103.idm.example.com,somehost.idm.example.com ------------------------- Number of members added 1 -------------------------
Optionally, display the ID view information. For example, to display the details about the example_for_host1 ID view:
[root@master ~]# ipa idview-show example_for_host1 --all dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_host1 [...] Hosts the view applies to: host102.idm.example.com, host103.idm.example.com objectclass: ipaIDView, top, nsContainer
The output shows that the ID view is not applied to somehost.idm.example.com, the newly-added host in the baltimore host group.
Apply the ID view to the new host. For example, to apply the example_for_host1 ID view to somehost.idm.example.com:
[root@master ~]# ipa idview-apply --host=somehost.idm.example.com ID View Name: example_for_host1 ----------------------------------------- Applied ID View "example_for_host1" ----------------------------------------- hosts: somehost.idm.example.com --------------------------------------------- Number of hosts the ID View was applied to: 1 ---------------------------------------------
Verification steps
Display the ID view information again:
[root@master ~]# ipa idview-show example_for_host1 --all dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com ID View Name: example_for_host1 [...] Hosts the view applies to: host102.idm.example.com, host103.idm.example.com, somehost.idm.example.com objectclass: ipaIDView, top, nsContainer
The output shows that ID view is now applied to somehost.idm.example.com, the newly-added host in the baltimore host group.
Chapter 24. Adjusting ID ranges manually
An IdM master generates unique user ID (UID) and group ID (GID) numbers. By creating and assigning different ID ranges to replicas, it also ensures that they never generate the same ID numbers. By default, this process is automatic. However, you can manually adjust the IdM ID range during the IdM master installation, or manually define a replica’s DNA ID range.
24.1. ID ranges
ID numbers are divided into ID ranges. Keeping separate numeric ranges for individual servers and replicas eliminates the chance that an ID number issued for an entry is already used by another entry on another server or replica.
Note that there are two distinct types of ID ranges:
- The IdM ID range, which is assigned during the IdM master installation. This range cannot be modified after it is created. However, if you need to, you can create a new IdM ID range in addition to the original one. For more information, see Automatic ID ranges assignment and Adding a new IdM ID range.
The Distributed Numeric Assignment (DNA) ID ranges, which can be modified by the user. These have to fit within an existing IdM ID range. For more information, see Adjusting DNA ID ranges manually.
Replicas can also have a next DNA ID range assigned. A replica uses its next range when it runs out of IDs in its current range. Next ranges are assigned automatically when a replica is deleted or you can set them manually.
The ranges are updated and shared between the master and replicas by the DNA plug-in, as part of the back end 389 Directory Server instance for the domain.
The DNA range definition is set by two attributes: the server’s next available number (the low end of the DNA range) and its maximum value (the top end of the DNA range). The initial bottom range is set during the plug-in instance configuration. After that, the plug-in updates the bottom value. Breaking the available numbers into ranges allows the servers to continually assign numbers without overlapping with each other.
24.2. Automatic ID ranges assignment
By default, an IdM ID range is automatically assigned during the IdM master installation. The ipa-server-install
command randomly selects and assigns a range of 200,000 IDs from a total of 10,000 possible ranges. Selecting a random range in this way significantly reduces the probability of conflicting IDs in case you decide to merge two separate IdM domains in the future.
This IdM ID range cannot be modified after it is created. You can only manually adjust the Distributed Numeric Assignment (DNA) ID ranges, using the commands described in Adjusting DNA ID ranges manually. A DNA range matching the IdM ID range is automatically created during installation.
If you have a single IdM server installed, it controls the whole DNA ID range. When you install a new replica and the replica requests its own DNA ID range, the initial ID range for the master splits and is distributed between the master and replica: the replica receives half of the remaining DNA ID range that is available on the initial master. The master and replica then use their respective portions of the original ID range for new user or group entries. Also, if the replica is close to depleting its allocated ID range and fewer than 100 IDs remain, the replica contacts the other available servers to request a new DNA ID range.
When you install a replica, it does not immediately receive an ID range. A replica receives an ID range the first time the DNA plug-in is used, for example when you first add a user. Until then, the replica has no ID range defined.
If the initial master stops functioning before the replica requests a DNA ID range from it, the replica is unable to contact the master to request the ID range. Attempting to add a new user on the replica then fails. In such situations, you can find out what ID range is assigned to the disabled master, and assign an ID range to the replica manually.
24.3. Assigning the IdM ID range manually during server installation
You can override the default behavior and set an IdM ID range manually instead of having it assigned randomly.
Do not set ID ranges that include UID values of 1000 and lower; these values are reserved for system use. Also, do not set an ID range that would include the 0 value; the SSSD service does not handle the 0 ID value.
Procedure
You can define the IdM ID range manually during server installation by using the following two options with
ipa-server-install
:-
--idstart
gives the starting value for UID and GID numbers. -
--idmax
gives the maximum UID and GID number; by default, the value is the--idstart
starting value plus 199,999.
-
Verification steps
To check if the ID range was assigned correctly, you can display the assigned IdM ID range by using the
ipa idrange-find
command:# ipa idrange-find --------------- 1 range matched --------------- Range name: IDM.EXAMPLE.COM_id_range First Posix ID of the range: 882200000 Number of IDs in the range: 200000 Range type: local domain range ---------------------------- Number of entries returned 1 ----------------------------
24.4. Adding a new IdM ID range
In some cases, you may want to create a new IdM ID range in addition to the original one; for example, when a replica has run out of IDs and the original IdM ID range is depleted.
Adding a new IdM ID range does not create new DNA ID ranges automatically. You need to assign new DNA ID ranges manually as needed. For more information on how to do this, see Adjusting DNA ID ranges manually.
Procedure
-
To create a new IdM ID range, use the
ipa idrange-add
command. You need to specify the new range name, the first ID number of the range and the range size:
# ipa idrange-add IDM.EXAMPLE.COM_new_range --base-id=1000000 --range-size=200000 ------------------------------------------ Added ID range "IDM.EXAMPLE.COM_new_range" ------------------------------------------ Range name: IDM.EXAMPLE.COM_new_range First Posix ID of the range: 1000000 Number of IDs in the range: 200000 Range type: local domain range
Verification steps
-
You can check if the new range is set correctly by using the
ipa idrange-find
command:
# ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: IDM.EXAMPLE.COM_id_range First Posix ID of the range: 882200000 Number of IDs in the range: 200000 Range type: local domain range Range name: IDM.EXAMPLE.COM_new_range First Posix ID of the range: 1000000 Number of IDs in the range: 200000 Range type: local domain range ---------------------------- Number of entries returned 2 ----------------------------
24.5. Displaying currently assigned DNA ID ranges
You can display both the currently active Distributed Numeric Assignment (DNA) ID range on a server, as well as its next DNA range if it has one assigned.
Procedure
To display which DNA ID ranges are configured for the servers in the topology, use the following commands:
ipa-replica-manage dnarange-show
displays the current DNA ID range that is set on all servers or, if you specify a server, only on the specified server, for example:# ipa-replica-manage dnarange-show masterA.example.com: 1001-1500 masterB.example.com: 1501-2000 masterC.example.com: No range set # ipa-replica-manage dnarange-show masterA.example.com masterA.example.com: 1001-1500
ipa-replica-manage dnanextrange-show
displays the next DNA ID range currently set on all servers or, if you specify a server, only on the specified server, for example:# ipa-replica-manage dnanextrange-show masterA.example.com: 2001-2500 masterB.example.com: No on-deck range set masterC.example.com: No on-deck range set # ipa-replica-manage dnanextrange-show masterA.example.com masterA.example.com: 2001-2500
24.6. Automatic DNA ID range extension
When you delete a functioning replica, the ipa-replica-manage del
command retrieves the DNA ID ranges that were assigned to the replica and adds them as a next range to another available IdM replica. This ensures that DNA ID ranges are used efficiently.
After you delete a replica, you can verify which DNA ID ranges are configured for other servers by using the commands described in Displaying currently assigned DNA ID ranges.
24.7. Manual DNA ID range adjustment
In certain situations, it is necessary to manually adjust a Distributed Numeric Assignment (DNA) ID range, for example when:
A replica has run out of IDs and the IdM ID range is depleted
A replica has exhausted the DNA ID range that was assigned to it, and requesting additional IDs failed because no more free IDs are available in the IdM range.
To solve this situation, extend the DNA ID range assigned to the replica. You can do this in two ways:
- Shorten the DNA ID range assigned to a different replica, then assign the newly available values to the depleted replica.
Create a new IdM ID range, then set a new DNA ID range for the replica within this created IdM range.
For information on how to create a new IdM ID range, see Adding a new IdM ID range.
A replica stopped functioning
A replica’s DNA ID range is not automatically retrieved when the replica dies and needs to be deleted, which means the DNA ID range previously assigned to the replica becomes unavailable. You want to recover the DNA ID range and make it available for other replicas.
If you want to recover a DNA ID range belonging to a replica that stopped functioning and assign it to another server, you first need to find out what the ID range values are, before manually assigning that range to a different server. Also, to avoid duplicate UIDs or GIDs, make sure that no ID value from the recovered range was previously assigned to a user or group; you can do this by examining the UIDs and GIDs of existing users and groups.
You can manually adjust a DNA ID range for a replica using the commands in Adjusting DNA ID ranges manually.
If you assign a new DNA ID range, the UIDs of the already existing entries on the server or replica stay the same. This does not pose a problem because even if you change the current DNA ID range, IdM keeps a record of what ranges were assigned in the past.
24.8. Adjusting DNA ID ranges manually
In some cases, you may need to manually adjust Distributed Numeric Assignment (DNA) ID ranges for existing replicas, for example to reassign a DNA ID range assigned to a non-functioning replica. For more information, see Manual DNA ID range adjustment.
When adjusting a DNA ID range manually, make sure that the newly adjusted range is included in the IdM ID range; you can check this using the ipa idrange-find
command. Otherwise, the command will fail.
Be careful not to create overlapping ID ranges. If any of the ID ranges you assign to servers or replicas overlap, it could result in two different servers assigning the same ID value to different entries.
Prerequisites
- Optional. If you are recovering a DNA ID range from a non-functioning replica, first find the ID range using the commands described in Displaying currently assigned DNA ID ranges.
Procedure
To define the current DNA ID range for a specified server, use the
ipa-replica-manage dnarange-set
:# ipa-replica-manage dnarange-set masterA.example.com 1250-1499
To define the next DNA ID range for a specified server, use the
ipa-replica-manage dnanextrange-set
:# ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000
Verification steps
- You can check that the new DNA ranges are set correctly by using the commands described in Displaying the currently assigned DNA ID ranges.
Chapter 25. Configuring IdM for external provisioning of users
As a system administrator, you can configure Identity Management (IdM) to support the provisioning of users by an external solution for managing identities.
Rather than use the ipa
utility, the administrator of the external provisioning system can access the IdM LDAP using the ldapmodify
utility. The administrator can add individual stage users from the CLI using ldapmodify or using an LDIF file.
The assumption is that you, as an IdM administrator, fully trust your external provisioning system to only add validated users. However, at the same time you do not want to assign the administrators of the external provisioning system the IdM role of User Administrator
to enable them to add new active users directly.
You can configure a script to automatically move the staged users created by the external provisioning system to active users automatically.
This chapter contains these sections:
- Preparing Identity Management (IdM) to use an external provisioning system to add stage users to IdM.
- Creating a script to move the users added by the external provisioning system from stage to active users.
Using an external provisioning system to add an IdM stage user. You can do that in two ways:
Additional materials
For examples and templates for using ldapmodify
as a full IdM administrator to perform user and group management operations that require higher privileges, see Using ldapmodify.
25.1. Preparing IdM accounts for automatic activation of stage user accounts
This procedure shows how to configure two IdM user accounts to be used by an external provisioning system. By adding the accounts to a group with an appropriate password policy, you enable the external provisioning system to manage user provisioning in IdM. In the following, the user account to be used by the external system to add stage users is named provisionator. The user account to be used to automatically activate the stage users is named activator.
Prerequisites
- The host on which you perform the procedure is enrolled into IdM.
Procedure
Log in as IdM administrator:
$ kinit admin
Create a user named provisionator with the privileges to add stage users.
- Add the provisionator user account:
$ ipa user-add provisionator --first=provisioning --last=account --password
Grant the provisionator user the required privileges.
Create a custom role,
System Provisioning
, to manage adding stage users:$ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
Add the
Stage User Provisioning
privilege to the role. This privilege provides the ability to add stage users:$ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
Add the provisionator user to the role:
$ ipa role-add-member --users=provisionator "System Provisioning"
- Verify that the provisionator exists in IdM:
$ ipa user-find provisionator --all --raw -------------- 1 user matched -------------- dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com uid: provisionator [...]
Create a user, activator, with the privileges to manage user accounts.
Add the activator user account:
$ ipa user-add activator --first=activation --last=account --password
Grant the activator user the required privileges by adding the user to the default
User Administrator
role:$ ipa role-add-member --users=activator "User Administrator"
Create a user group for application accounts:
$ ipa group-add application-accounts
Update the password policy for the group. The following policy prevents password expiration and lockout for the account but compensates the potential risks by requiring complex passwords:
$ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
(Optional) Verify that the password policy exists in IdM:
$ ipa pwpolicy-show application-accounts Group: application-accounts Max lifetime (days): 10000 Min lifetime (hours): 0 History size: 0 [...]
Add the provisioning and activation accounts to the group for application accounts:
$ ipa group-add-member application-accounts --users={provisionator,activator}
Change the passwords for the user accounts:
$ kpasswd provisionator $ kpasswd activator
Changing the passwords is necessary because new IdM users passwords expire immediately.
Additional resources:
- For details on adding new users, see Managing user accounts using the command line.
- For details on granting users the privileges required to manage other user accounts, see Delegating Permissions over Users.
- For details on managing IdM password policies, see Defining IdM Password Policies.
25.2. Configuring automatic activation of IdM stage user accounts
This procedure shows how to create a script for activating stage users. The system runs the script automatically at specified time intervals. This ensures that new user accounts are automatically activated and available for use shortly after they are created.
The procedure assumes that the owner of the external provisioning system has already validated the users and that they do not require additional validation on the IdM side before the script adds them to IdM.
It is sufficient to enable the activation process on only one of your IdM servers.
Prerequisites
- The provisionator and activator accounts exist in IdM. For details, see Preparing IdM accounts for automatic activation of stage user accounts.
- You have root privileges on the IdM server on which you are running the procedure.
- You are logged in as IdM administrator.
- You trust your external provisioning system.
Procedure
Generate a keytab file for the activation account:
# ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
If you want to enable the activation process on more than one IdM server, generate the keytab file on one server only. Then copy the keytab file to the other servers.
Create a script,
/usr/local/sbin/ipa-activate-all
, with the following contents to activate all users:#!/bin/bash kinit -k -i activator ipa stageuser-find --all --raw | grep " uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
Edit the permissions and ownership of the
ipa-activate-all
script to make it executable:# chmod 755 /usr/local/sbin/ipa-activate-all # chown root:root /usr/local/sbin/ipa-activate-all
Create a systemd unit file,
/etc/systemd/system/ipa-activate-all.service
, with the following contents:[Unit] Description=Scan IdM every minute for any stage users that must be activated [Service] Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all ExecStart=/usr/local/sbin/ipa-activate-all
Create a systemd timer,
/etc/systemd/system/ipa-activate-all.timer
, with the following contents:[Unit] Description=Scan IdM every minute for any stage users that must be activated [Timer] OnBootSec=15min OnUnitActiveSec=1min [Install] WantedBy=multi-user.target
Reload the new configuration:
# systemctl daemon-reload
Enable
ipa-activate-all.timer
:# systemctl enable ipa-activate-all.timer
Start
ipa-activate-all.timer
:# systemctl start ipa-activate-all.timer
(Optional) Verify that the
ipa-activate-all.timer
daemon is running:# systemctl status ipa-activate-all.timer ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled) Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.
25.3. Adding an IdM stage user defined in an LDIF file
This section describes how an administrator of an external provisioning system can access IdM LDAP and use an LDIF file to add stage users. While the example below shows adding one single user, multiple users can be added in one file in bulk mode.
Prerequisites
- IdM administrator has created the provisionator account and a password for it. For details, see Preparing IdM accounts for automatic activation of stage user accounts.
- You as the external administrator know the password of the provisionator account.
- You can SSH to the IdM server from your LDAP server.
You are able to supply the minimal set of attributes that an IdM stage user must have to allow the correct processing of the user life cycle, namely:
-
The
distinguished name
(dn) -
The
common name
(cn) -
The
last name
(sn) -
The
uid
-
The
Procedure
On the external server, create an LDIF file that contains information about the new user:
dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: stageidmuser sn: surname givenName: first_name cn: full_name
Transfer the LDIF file from the external server to the IdM server:
$ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/ Password: add-stageidmuser.ldif 100% 364 217.6KB/s 00:00
Use the
SSH
protocol to connect to the IdM server as provisionator:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
On the IdM server, obtain the Kerberos ticket-granting ticket (TGT) for the provisionator account:
[provisionator@server ~]$ kinit provisionator
Enter the
ldapadd
command with the -f option and the name of the LDIF file. Specify the name of the IdM server and the port number:~]$ ldapadd -h server.idm.example.com -p 389 -f add-stageidmuser.ldif SASL/GSSAPI authentication started SASL username: provisionator@IDM.EXAMPLE.COM SASL SSF: 256 SASL data security layer installed. adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
25.4. Adding an IdM stage user directly from the CLI using ldapmodify
This section describes how an administrator of an external provisioning system can access the Identity Management (IdM) LDAP and use the ldapmodify
utility to add a stage user.
Prerequisites
- The IdM administrator has created the provisionator account and a password for it. For details, see Preparing IdM accounts for automatic activation of stage user accounts.
- You as the external administrator know the password of the provisionator account.
- You can SSH to the IdM server from your LDAP server.
You are able to supply the minimal set of attributes that an IdM stage user must have to allow the correct processing of the user life cycle, namely:
-
The
distinguished name
(dn) -
The
common name
(cn) -
The
last name
(sn) -
The
uid
-
The
Procedure
Use the
SSH
protocol to connect to the IdM server using your IdM identity and credentials:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
Obtain the TGT of the provisionator account, an IdM user with a role to add new stage users:
$ kinit provisionator
Enter the
ldapmodify
command and specify Generic Security Services API (GSSAPI) as the Simple Authentication and Security Layer (SASL) mechanism to use for authentication. Specify the name of the IdM server and the port:# ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI SASL/GSSAPI authentication started SASL username: provisionator@IDM.EXAMPLE.COM SASL SSF: 56 SASL data security layer installed.
Enter the
dn
of the user you are adding:dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Enter add as the type of change you are performing:
changetype: add
Specify the LDAP object class categories required to allow the correct processing of the user life cycle:
objectClass: top objectClass: inetorgperson
You can specify additional object classes.
Enter the
uid
of the user:uid: stageuser
Enter the
cn
of the user:cn: Babs Jensen
Enter the last name of the user:
sn: Jensen
Press
Enter
again to confirm that this is the end of the entry:[Enter] adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
- Exit the connection using Ctrl + C.
Verification steps
Verify the contents of the stage entry to make sure your provisioning system added all required POSIX attributes and the stage entry is ready to be activated.
To display the new stage user’s LDAP attributes, enter the
ipa stageuser-show --all --raw
command:$ ipa stageuser-show stageuser --all --raw dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com uid: stageuser sn: Jensen cn: Babs Jensen has_password: FALSE has_keytab: FALSE nsaccountlock: TRUE objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person
-
Note that the user is explicitly disabled by the
nsaccountlock
attribute.
-
Note that the user is explicitly disabled by the
Chapter 26. Using ldapmodify to manage IdM users externally
You can modify Identity Management (IdM) LDAP directly from the command-line interface (CLI) using the ldapmodify
and ldapdelete
utilities. The utilities provide full functionality for adding, editing, and deleting your directory contents. You can use these utilities to manage both the configuration entries of the server and the data in the user entries. The utilities can also be used to write scripts to perform bulk management of one or more directories.
26.1. Templates for managing IdM user accounts externally
This section describes templates for various user management operations in IdM. The templates show which attributes you must modify using ldapmodify
to achieve the following goals:
- Adding a new stage user
- Modifying a user’s attribute
- Enabling a user
- Disabling a user
- Preserving a user
The templates are formatted in the LDAP Data Interchange Format (LDIF). LDIF is a standard plain text data interchange format for representing LDAP directory content and update requests.
Using the templates, you can configure the LDAP provider of your provisioning system to manage IdM user accounts.
For detailed example procedures, see the following sections:
Templates for adding a new stage user
A template for adding a user with UID and GID assigned automatically. The distinguished name (DN) of the created entry must start with
uid=user_login
:dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: user_login sn: surname givenName: first_name cn: full_name
A template for adding a user with UID and GID assigned statically:
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: posixaccount uid: user_login uidNumber: UID_number gidNumber: GID_number sn: surname givenName: first_name cn: full_name homeDirectory: /home/user_login
You are not required to specify any IdM object classes when adding stage users. IdM adds these classes automatically after the users are activated.
Templates for modifying existing users
Modifying a user’s attribute:
dn: distinguished_name changetype: modify replace: attribute_to_modify attribute_to_modify: new_value
Disabling a user:
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: TRUE
Enabling a user:
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: FALSE
Updating the
nssAccountLock
attribute has no effect on stage and preserved users. Even though the update operation completes successfully, the attribute value remainsnssAccountLock: TRUE
.Preserving a user:
dn: distinguished_name changetype: modrdn newrdn: uid=user_login deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Before modifying a user, obtain the user’s distinguished name (DN) by searching using the user’s login. In the following example, the user_allowed_to_modify_user_entries user is a user allowed to modify user and group information, for example activator or IdM administrator. The password in the example is this user’s password:
[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
26.2. Templates for managing IdM group accounts externally
This section describes templates for various user group management operations in IdM. The templates show which attributes you must modify using ldapmodify
to achieve the following aims:
- Creating a new group
- Deleting an existing group
- Adding a member to a group
- Removing a member from a group
The templates are formatted in the LDAP Data Interchange Format (LDIF). LDIF is a standard plain text data interchange format for representing LDAP directory content and update requests.
Using the templates, you can configure the LDAP provider of your provisioning system to manage IdM group accounts.
Creating a new group
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: ipaobject objectClass: ipausergroup objectClass: groupofnames objectClass: nestedgroup objectClass: posixgroup uid: group_name cn: group_name gidNumber: GID_number
Modifying groups
Deleting an existing group:
dn: group_distinguished_name changetype: delete
Adding a member to a group:
dn: group_distinguished_name changetype: modify add: member member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Do not add stage or preserved users to groups. Even though the update operation completes successfully, the users will not be updated as members of the group. Only active users can belong to groups.
Removing a member from a group:
dn: distinguished_name changetype: modify delete: member member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Before modifying a group, obtain the group’s distinguished name (DN) by searching using the group’s name.
# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017
26.3. Preserving an IdM user with ldapmodify
This section describes how to use ldapmodify
to preserve an IdM user; that is, how to deactivate a user account after the employee has left the company.
Prerequisites
- You can authenticate as an IdM user with a role to preserve users.
Procedure
Log in as an IdM user with a role to preserve users:
$ kinit admin
Enter the
ldapmodify
command and specify the Generic Security Services API (GSSAPI) as the Simple Authentication and Security Layer (SASL) mechanism to be used for authentication:# ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@IDM.EXAMPLE.COM SASL SSF: 256 SASL data security layer installed.
Enter the
dn
of the user you want to preserve:dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Enter modrdn as the type of change you want to perform:
changetype: modrdn
Specify the newrdn for the user:
newrdn: uid=user1
Indicate that you want to preserve the user:
deleteoldrdn: 0
Specify the new superior DN:
newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Preserving a user moves the entry to a new location in the directory information tree (DIT). For this reason, you must specify the DN of the new parent entry as the new superior DN.
Press
Enter
again to confirm that this is the end of the entry:[Enter] modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
- Exit the connection using Ctrl + C.
Verification steps
Verify that the user has been preserved by listing all preserved users:
$ ipa user-find --preserved=true -------------- 1 user matched -------------- User login: user1 First name: First 1 Last name: Last 1 Home directory: /home/user1 Login shell: /bin/sh Principal name: user1@IDM.EXAMPLE.COM Principal alias: user1@IDM.EXAMPLE.COM Email address: user1@idm.example.com UID: 1997010003 GID: 1997010003 Account disabled: True Preserved user: True ---------------------------- Number of entries returned 1 ----------------------------
Chapter 27. Managing Hosts in IdM CLI
This chapter introduces hosts and host entries in Identity Management (IdM), and the following operations performed when managing hosts and host entries in IdM CLI:
The chapter also contains an overview table of the prerequisites, the context, and the consequences of these operations.
27.1. Hosts in IdM
Identity Management (IdM) manages these identities:
- Users
- Services
- Hosts
A host represents a machine. As an IdM identity, a host has an entry in the IdM LDAP, that is the 389 Directory Server instance of the IdM server.
The host entry in IdM LDAP is used to establish relationships between other hosts and even services within the domain. These relationships are part of delegating authorization and control to hosts within the domain. Any host can be used in host-based access control
(HBAC) rules.
IdM domain establishes a commonality between machines, with common identity information, common policies, and shared services. Any machine that belongs to a domain functions as a client of the domain, which means it uses the services that the domain provides. IdM domain provides three main services specifically for machines:
- DNS
- Kerberos
- Certificate management
Hosts in IdM are closely connected with the services running on them:
- Service entries are associated with a host.
- A host stores both the host and the service Kerberos principals.
27.2. Host enrollment
This section describes enrolling hosts as IdM clients and what happens during and after the enrollment. The section compares the enrollment of IdM hosts and IdM users. The section also outlines alternative types of authentication available to hosts.
Enrolling a host consists of:
-
Creating a host entry in IdM LDAP: possibly using the
ipa host-add
command in IdM CLI, or the equivalent IdM Web UI operation. - Configuring IdM services on the host, for example the System Security Services Daemon (SSSD), Kerberos, and certmonger, and joining the host to the IdM domain.
The two actions can be performed separately or together.
If performed separately, they allow for dividing the two tasks between two users with different levels of privilege. This is useful for bulk deployments.
The ipa-client-install
command can perform the two actions together. The command creates a host entry in IdM LDAP if that entry does not exist yet, and configures both the Kerberos and SSSD services for the host. The command brings the host within the IdM domain and allows it to identify the IdM server it will connect with. If the host belongs to a DNS zone managed by IdM, ipa-client-install
adds DNS records for the host too. The command must be run on the client.
27.2.1. User privileges required for host enrollment
The host enrollment operation requires authentication to prevent an unprivileged user from adding unwanted machines to the IdM domain. The privileges required depend on several factors, for example:
-
If a host entry is created separately from running
ipa-client-install
- If a one-time password (OTP) is used for enrollment
User privileges for optionally manually creating a host entry in IdM LDAP
The user privilege required for creating a host entry in IdM LDAP using the ipa host-add
CLI command or the IdM Web UI is Host Administrators
. The Host Administrators
privilege can be obtained through the IT Specialist
role.
User privileges for joining the client to the IdM domain
Hosts are configured as IdM clients during the execution of the ipa-client-install
command. The level of credentials required for executing the ipa-client-install
command depends on which of the following enrolling scenarios you find yourself in:
-
The host entry in IdM LDAP does not exist. For this scenario, you need a full administrator’s credentials or the
Host Administrators
role. A full administrator is a member of theadmins
group. TheHost Administrators
role provides privileges to add hosts and enroll hosts. For details about this scenario, see Installing a client using user credentials: interactive installation. -
The host entry in IdM LDAP exists. For this scenario, you need a limited administrator’s credentials to execute
ipa-client-install
successfully. The limited administrator in this case has theEnrollment Administrator
role, which provides theHost Enrollment
privilege. For details, see Installing a client using user credentials: interactive installation. -
The host entry in IdM LDAP exists, and an OTP has been generated for the host by a full or limited administrator. For this scenario, you can install an IdM client as an ordinary user if you run the
ipa-client-install
command with the--password
option, supplying the correct OTP. For details, see Installing a client by using a one-time password: Interactive installation.
After enrollment, IdM hosts authenticate every new session to be able to access IdM resources. Machine authentication is required for the IdM server to trust the machine and to accept IdM connections from the client software installed on that machine. After authenticating the client, the IdM server can respond to its requests.
27.2.2. Enrollment and authentication of IdM hosts and users: comparison
There are many similarities between users and hosts in IdM. This section describes some of the similarities that can be observed during the enrollment stage as well as those that concern authentication during the deployment stage.
The enrollment stage (Table 27.1, “User and host enrollment”):
-
An administrator can create an LDAP entry for both a user and a host before the user or host actually join IdM: for the stage user, the command is
ipa stageuser-add
; for the host, the command isipa host-add
. -
A file containing a key table or, abbreviated, keytab, a symmetric key resembling to some extent a user password, is created during the execution of the
ipa-client-install
command on the host, resulting in the host joining the IdM realm. Analogically, a user is asked to create a password when they activate their account, thus joining the IdM realm. - While the user password is the default authentication method for a user, the keytab is the default authentication method for a host. The keytab is stored in a file on the host.
Table 27.1. User and host enrollment
Action User Host Pre-enrollment
$ ipa stageuser-add user_name [--password]
$ ipa host-add host_name [--random]
Activating the account
$ ipa stageuser-activate user_name
$ ipa-client install [--password] (must be run on the host itself)
-
An administrator can create an LDAP entry for both a user and a host before the user or host actually join IdM: for the stage user, the command is
The deployment stage (Table 27.2, “User and host session authentication”):
- When a user starts a new session, the user authenticates using a password; similarly, every time it is switched on, the host authenticates by presenting its keytab file. The System Security Services Daemon (SSSD) manages this process in the background.
- If the authentication is successful, the user or host obtains a Kerberos ticket granting ticket (TGT).
- The TGT is then used to obtain specific tickets for specific services.
Table 27.2. User and host session authentication
User Host Default means of authentication
Password
Keytabs
Starting a session (ordinary user)
$ kinit user_name
[switch on the host]
The result of successful authentication
TGT to be used to obtain access to specific services
TGT to be used to obtain access to specific services
TGTs and other Kerberos tickets are generated as part of the Kerberos services and policies defined by the server. The initial granting of a Kerberos ticket, the renewing of the Kerberos credentials, and even the destroying of the Kerberos session are all handled automatically by the IdM services.
27.2.3. Alternative authentication options for IdM hosts
Apart from keytabs, IdM supports two other types of machine authentication:
- SSH keys. The SSH public key for the host is created and uploaded to the host entry. From there, the System Security Services Daemon (SSSD) uses IdM as an identity provider and can work in conjunction with OpenSSH and other services to reference the public keys located centrally in IdM.
- Machine certificates. In this case, the machine uses an SSL certificate that is issued by the IdM server’s certificate authority and then stored in IdM’s Directory Server. The certificate is then sent to the machine to present when it authenticates to the server. On the client, certificates are managed by a service called certmonger.
27.3. Host Operations
This section lists the most common operations related to host enrollment and enablement, and explains the prerequisites, the context, and the consequences of performing them.
Table 27.3. Host operations part 1
Action | What are the prerequisites of the action? | When does it make sense to run the command? | How is the action performed by a system administrator? What command(s) does he run? |
---|---|---|---|
| see Preparing the system for Identity Management client installation in Installing_Identity_Management | When you want the host to join the IdM realm. |
Enrolling machines as clients in the IdM domain is a two-part process. A host entry is created for the client (and stored in the 389 Directory Server instance) when the |
| The host must have an entry in IdM. The host needs to have an active keytab. | When you want to remove the host from the IdM realm temporarily, perhaps for maintenance purposes. |
|
| The host must have an entry in IdM. | When you want the temporarily disabled host to become active again. |
|
| The host must have en entry in IdM. | When the original host has been lost but you have installed a host with the same host name. |
|
| The host must have an entry in IdM. | When you want to remove the host from the IdM realm permanently. |
|
Table 27.4. Host operations part 2
Action | On which machine can the administrator run the command(s)? | What happens when the action is performed? What are the consequences for the host’s functioning in IdM? What limitations are introduced/removed? |
---|---|---|
|
In the case of a two-step enrollment: | By default this configures SSSD to connect to an IdM server for authentication and authorization. Optionally one can instead configure the Pluggable Authentication Module (PAM) and the Name Switching Service (NSS) to work with an IdM server over Kerberos and LDAP. |
| Any machine in IdM, even the host itself | The host’s Kerberos key and SSL certificate are invalidated, and all services running on the host are disabled. |
| Any machine in IdM. If run on the disabled host, LDAP credentials need to be supplied. | The host’s Kerberos key and the SSL certificate are made valid again, and all IdM services running on the host are re-enabled. |
| The host to be re-enrolled. LDAP credentials need to be supplied. | A new Kerberos key is generated for the host, replacing the previous one. |
| The host to be un-enrolled. |
The command unconfigures IdM and attempts to return the machine to its previous state. Part of this process is to unenroll the host from the IdM server. Unenrollment consists of disabling the principal key on the IdM server. The machine principal in |
27.4. Host entry in IdM LDAP
This section describes what a host entry in Identity Management (IdM) looks like and what attributes it can contain.
An LDAP host entry contains all relevant information about the client within IdM:
- Service entries associated with the host
- The host and service principal
- Access control rules
- Machine information, such as its physical location and operating system
Note that the IdM Web UI Identity
→ Hosts
tab does not show all the information about a particular host stored in the IdM LDAP.
27.4.1. Host entry configuration properties
A host entry can contain information about the host that is outside its system configuration, such as its physical location, MAC address, keys, and certificates.
This information can be set when the host entry is created if it is created manually. Alternatively, most of this information can be added to the host entry after the host is enrolled in the domain.
Table 27.5. Host Configuration Properties
UI Field | Command-Line Option | Description |
---|---|---|
Description |
| A description of the host. |
Locality |
| The geographic location of the host. |
Location |
| The physical location of the host, such as its data center rack. |
Platform |
| The host hardware or architecture. |
Operating system |
| The operating system and version for the host. |
MAC address |
|
The MAC address for the host. This is a multi-valued attribute. The MAC address is used by the NIS plug-in to create a NIS |
SSH public keys |
| The full SSH public key for the host. This is a multi-valued attribute, so multiple keys can be set. |
Principal name (not editable) |
|
The Kerberos principal name for the host. This defaults to the host name during the client installation, unless a different principal is explicitly set in the |
Set One-Time Password |
| This option sets a password for the host which can be used in bulk enrollment. |
- |
| This option generates a random password to be used in bulk enrollment. |
- |
| A certificate blob for the host. |
- |
| This sets whether the host can dynamically update its DNS entries if its IP address changes. |
27.5. Adding IdM host entries from IdM CLI
This section describes how to add host entries in Identity Management (IdM) using the command-line interface (CLI).
Host entries are created using the host-add
command. This commands adds the host entry to the IdM Directory Server. Consult the ipa host
manpage by typing ipa help host
in your CLI to get the full list of options available with host-add
.
There are a few different scenarios when adding a host to IdM:
At its most basic, specify only the client host name to add the client to the Kerberos realm and to create an entry in the IdM LDAP server:
$ ipa host-add client1.example.com
If the IdM server is configured to manage DNS, add the host to the DNS resource records using the
--ip-address
option.Example 27.1. Creating Host Entries with Static IP Addresses
$ ipa host-add --ip-address=192.168.166.31 client1.example.com
If the host to be added does not have a static IP address or if the IP address is not known at the time the client is configured, use the
--force
option with theipa host-add
command.Example 27.2. Creating Host Entries with DHCP
$ ipa host-add --force client1.example.com
For example, laptops may be preconfigured as IdM clients, but they do not have IP addresses at the time they are configured. Using
--force
essentially creates a placeholder entry in the IdM DNS service. When the DNS service dynamically updates its records, the host’s current IP address is detected and its DNS record is updated.
27.6. Deleting host entries from IdM CLI
Use the
host-del
command to delete host records. If your IdM domain has integrated DNS, use the--updatedns
option to remove the associated records of any kind for the host from the DNS:$ ipa host-del --updatedns client1.example.com
27.7. Re-enrolling an Identity Management client
27.7.1. Client re-enrollment in IdM
This section describes how to re-enroll an Identity Management (IdM) client.
If a client machine has been destroyed and lost connection with the IdM servers, for example due to the client’s hardware failure, and you still have its keytab, you can re-enroll the client. In this scenario, you want to get the client back in the IdM environment with the same hostname.
During the re-enrollment, the client generates a new Kerberos key and SSH keys, but the identity of the client in the LDAP database remains unchanged. After the re-enrollment, the host has its keys and other information in the same LDAP object with the same FQDN
as previously, before the machine’s loss of connection with the IdM servers.
You can only re-enroll clients whose domain entry is still active. If you uninstalled a client (using ipa-client-install --uninstall
) or disabled its host entry (using ipa host-disable
), you cannot re-enroll it.
You cannot re-enroll a client after you have renamed it. This is because in Identity Management, the key attribute of the client’s entry in LDAP is the client’s hostname, its FQDN
. As opposed to re-enrolling a client, during which the client’s LDAP object remains unchanged, the outcome of renaming a client is that the client has its keys and other information in a different LDAP object with a new FQDN
. Thus the only way to rename a client is to uninstall the host from IdM, change the host’s hostname, and install it as an IdM client with a new name. For details on how to rename a client, see Section 27.8, “Renaming Identity Management client systems”.
27.7.1.1. What happens during client re-enrollment
During re-enrollment, Identity Management:
- Revokes the original host certificate
- Creates new SSH keys
- Generates a new keytab
27.7.2. Re-enrolling a client by using user credentials: Interactive re-enrollment
This procedure describes re-enrolling an Identity Management client interactively by using the credentials of an authorized user.
- Re-create the client machine with the same host name.
Run the
ipa-client-install --force-join
command on the client machine:# ipa-client-install --force-join
The script prompts for a user whose identity will be used to re-enroll the client. This could be, for example, a
hostadmin
user with the Enrollment Administrator role:User authorized to enroll computers:
hostadmin
Password forhostadmin
@EXAMPLE.COM
:
Additional resources
- For a more detailed procedure on enrolling clients by using an authorized user’s credentials, see Installing a client by using user credentials: Interactive installation in Installing Identity Management.
27.7.3. Re-enrolling a client by using the client keytab: Non-interactive re-enrollment
Prerequisites
-
Back up the original client keytab file, for example in the
/tmp
or/root
directory.
Procedure
This procedure describes re-enrolling an Identity Management (IdM) client non-interactively by using the keytab of the client system. For example, re-enrollment using the client keytab is appropriate for an automated installation.
- Re-create the client machine with the same host name.
-
Copy the keytab file from the backup location to the
/etc/
directory on the re-created client machine. Use the
ipa-client-install
utility to re-enroll the client, and specify the keytab location with the--keytab
option:# ipa-client-install --keytab /etc/krb5.keytab
NoteThe keytab specified in the
--keytab
option is only used when authenticating to initiate the enrollment. During the re-enrollment, IdM generates a new keytab for the client.
27.7.4. Testing an Identity Management client after installation
The Command-Line Interface informs you that the ipa-client-install
was successful, but you can also do your own test.
To test that the Identity Management client can obtain information about users defined on the server, check that you are able to resolve a user defined on the server. For example, to check the default admin
user:
[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)
To test that authentication works correctly, su -
as another IdM user:
[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$
27.8. Renaming Identity Management client systems
The following sections describe how to change the host name of an Identity Management client system.
Renaming a client is a manual procedure. Do not perform it unless changing the host name is absolutely required.
Renaming an Identity Management client involves:
- Preparing the host. For details, see Section 27.8.1, “Prerequisites”
- Uninstalling the IdM client from the host. For details, see Section 27.8.2, “Uninstalling an Identity Management client”
- Renaming the host. For details, see Section 27.8.3, “Renaming the host system”
- Installing the IdM client on the host with the new name. For details, see Section 27.8.4, “Re-installing an Identity Management client”
- Configuring the host after the IdM client installation. For details, see Section 27.8.5, “Re-adding services, re-generating certificates, and re-adding host groups”
27.8.1. Prerequisites
Before uninstalling the current client, make note of certain settings for the client. You will apply this configuration after re-enrolling the machine with a new host name.
Identify which services are running on the machine:
Use the
ipa service-find
command, and identify services with certificates in the output:$ ipa service-find old-client-name.example.com
-
In addition, each host has a default host service which does not appear in the
ipa service-find
output. The service principal for the host service, also called a host principal, ishost/old-client-name.example.com
.
For all service principals displayed by
ipa service-find old-client-name.example.com
, determine the location of the corresponding keytabs on theold-client-name.example.com
system:# find / -name "*.keytab"
Each service on the client system has a Kerberos principal in the form service_name/host_name@REALM, such as
ldap/old-client-name.example.com@EXAMPLE.COM
.Identify all host groups to which the machine belongs.
# ipa hostgroup-find old-client-name.example.com
27.8.2. Uninstalling an Identity Management client
Uninstalling a client removes the client from the Identity Management domain, along with all of the specific Identity Management configuration of system services, such as System Security Services Daemon (SSSD). This restores the previous configuration of the client system.
Procedure
Run the
ipa-client-install --uninstall
command:[root@client]# ipa-client-install --uninstall
Remove the DNS entries for the client host manually from the server:
[root@server]# ipa dnsrecord-del Record name: old-client-client Zone name: idm.example.com No option to delete specific record provided. Delete all? Yes/No (default No): yes ------------------------ Deleted record "old-client-name"
For each identified keytab other than
/etc/krb5.keytab
, remove the old principals:[root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
On an IdM server, remove the host entry. This removes all services and revokes all certificates issued for that host:
[root@server ~]# ipa host-del client.example.com
27.8.3. Renaming the host system
Rename the machine as required. For example:
[root@client]# hostnamectl set-hostname new-client-name.example.com
You can now re-install the Identity Management client to the Identity Management domain with the new host name.
27.8.4. Re-installing an Identity Management client
Install an client on your renamed host following the procedure described in Installing an Identity Management client: Basic scenario in Installing Identity Management.
27.8.5. Re-adding services, re-generating certificates, and re-adding host groups
On the Identity Management (IdM) server, add a new keytab for every service identified in Section 27.8.1, “Prerequisites”.
[root@server ~]# ipa service-add service_name/new-client-name
Generate certificates for services that had a certificate assigned in Section 27.8.1, “Prerequisites”. You can do this:
- Using the IdM administration tools
-
Using the
certmonger
utility
- Re-add the client to the host groups identified in Section 27.8.1, “Prerequisites”.
27.9. Disabling and Re-enabling Host Entries
This section describes how to disable and re-enable hosts in Identity Management (IdM).
27.9.1. Disabling Hosts
Complete this procedure to disable a host entry in IdM.
Domain services, hosts, and users can access an active host. There can be situations when it is necessary to remove an active host temporarily, for maintenance reasons, for example. Deleting the host in such situations is not desired as it removes the host entry and all the associated configuration permanently. Instead, choose the option of disabling the host.
Disabling a host prevents domain users from accessing it without permanently removing it from the domain. This can be done by using the host-disable
command. Disabling a host kills the host’s current, active keytabs.
For example:
$ kinit admin $ ipa host-disable client.example.com
As a result of disabling a host, the host becomes unavailable to all IdM users, hosts and services.
Disabling a host entry not only disables that host. It disables every configured service on that host as well.
27.9.2. Re-enabling Hosts
This section describes how to re-enable a disabled IdM host.
Disabling a host killed its active keytabs, which removed the host from the IdM domain without otherwise touching its configuration entry.
To re-enable a host, use the ipa-getkeytab
command, adding:
-
the
-s
option to specify which IdM server to request the keytab from -
the
-p
option to specify the principal name -
the
-k
option to specify the file to which to save the keytab.
For example, to request a new host keytab from server.example.com
for client.example.com
, and store the keytab in the /etc/krb5.keytab
file:
$ ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
You can also use the administrator’s credentials, specifying -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com"
. It is important that the credentials correspond to a user allowed to create the keytab for the host.
If the ipa-getkeytab
command is run on an active IdM client or server, then it can be run without any LDAP credentials (-D
and -w
) if the user has a TGT obtained using, for example, kinit admin
. To run the command directly on the disabled host, supply LDAP credentials to authenticate to the IdM server.
Chapter 28. Adding host entries from IdM Web UI
This chapter introduces hosts in Identity Management (IdM) and the operation of adding a host entry in the IdM Web UI.
28.1. Hosts in IdM
Identity Management (IdM) manages these identities:
- Users
- Services
- Hosts
A host represents a machine. As an IdM identity, a host has an entry in the IdM LDAP, that is the 389 Directory Server instance of the IdM server.
The host entry in IdM LDAP is used to establish relationships between other hosts and even services within the domain. These relationships are part of delegating authorization and control to hosts within the domain. Any host can be used in host-based access control
(HBAC) rules.
IdM domain establishes a commonality between machines, with common identity information, common policies, and shared services. Any machine that belongs to a domain functions as a client of the domain, which means it uses the services that the domain provides. IdM domain provides three main services specifically for machines:
- DNS
- Kerberos
- Certificate management
Hosts in IdM are closely connected with the services running on them:
- Service entries are associated with a host.
- A host stores both the host and the service Kerberos principals.
28.2. Host enrollment
This section describes enrolling hosts as IdM clients and what happens during and after the enrollment. The section compares the enrollment of IdM hosts and IdM users. The section also outlines alternative types of authentication available to hosts.
Enrolling a host consists of:
-
Creating a host entry in IdM LDAP: possibly using the
ipa host-add
command in IdM CLI, or the equivalent IdM Web UI operation. - Configuring IdM services on the host, for example the System Security Services Daemon (SSSD), Kerberos, and certmonger, and joining the host to the IdM domain.
The two actions can be performed separately or together.
If performed separately, they allow for dividing the two tasks between two users with different levels of privilege. This is useful for bulk deployments.
The ipa-client-install
command can perform the two actions together. The command creates a host entry in IdM LDAP if that entry does not exist yet, and configures both the Kerberos and SSSD services for the host. The command brings the host within the IdM domain and allows it to identify the IdM server it will connect with. If the host belongs to a DNS zone managed by IdM, ipa-client-install
adds DNS records for the host too. The command must be run on the client.
28.2.1. User privileges required for host enrollment
The host enrollment operation requires authentication to prevent an unprivileged user from adding unwanted machines to the IdM domain. The privileges required depend on several factors, for example:
-
If a host entry is created separately from running
ipa-client-install
- If a one-time password (OTP) is used for enrollment
User privileges for optionally manually creating a host entry in IdM LDAP
The user privilege required for creating a host entry in IdM LDAP using the ipa host-add
CLI command or the IdM Web UI is Host Administrators
. The Host Administrators
privilege can be obtained through the IT Specialist
role.
User privileges for joining the client to the IdM domain
Hosts are configured as IdM clients during the execution of the ipa-client-install
command. The level of credentials required for executing the ipa-client-install
command depends on which of the following enrolling scenarios you find yourself in:
-
The host entry in IdM LDAP does not exist. For this scenario, you need a full administrator’s credentials or the
Host Administrators
role. A full administrator is a member of theadmins
group. TheHost Administrators
role provides privileges to add hosts and enroll hosts. For details about this scenario, see Installing a client using user credentials: interactive installation. -
The host entry in IdM LDAP exists. For this scenario, you need a limited administrator’s credentials to execute
ipa-client-install
successfully. The limited administrator in this case has theEnrollment Administrator
role, which provides theHost Enrollment
privilege. For details, see Installing a client using user credentials: interactive installation. -
The host entry in IdM LDAP exists, and an OTP has been generated for the host by a full or limited administrator. For this scenario, you can install an IdM client as an ordinary user if you run the
ipa-client-install
command with the--password
option, supplying the correct OTP. For details, see Installing a client by using a one-time password: Interactive installation.
After enrollment, IdM hosts authenticate every new session to be able to access IdM resources. Machine authentication is required for the IdM server to trust the machine and to accept IdM connections from the client software installed on that machine. After authenticating the client, the IdM server can respond to its requests.
28.2.2. Enrollment and authentication of IdM hosts and users: comparison
There are many similarities between users and hosts in IdM. This section describes some of the similarities that can be observed during the enrollment stage as well as those that concern authentication during the deployment stage.
The enrollment stage (Table 28.1, “User and host enrollment”):
-
An administrator can create an LDAP entry for both a user and a host before the user or host actually join IdM: for the stage user, the command is
ipa stageuser-add
; for the host, the command isipa host-add
. -
A file containing a key table or, abbreviated, keytab, a symmetric key resembling to some extent a user password, is created during the execution of the
ipa-client-install
command on the host, resulting in the host joining the IdM realm. Analogically, a user is asked to create a password when they activate their account, thus joining the IdM realm. - While the user password is the default authentication method for a user, the keytab is the default authentication method for a host. The keytab is stored in a file on the host.
Table 28.1. User and host enrollment
Action User Host Pre-enrollment
$ ipa stageuser-add user_name [--password]
$ ipa host-add host_name [--random]
Activating the account
$ ipa stageuser-activate user_name
$ ipa-client install [--password] (must be run on the host itself)
-
An administrator can create an LDAP entry for both a user and a host before the user or host actually join IdM: for the stage user, the command is
The deployment stage (Table 28.2, “User and host session authentication”):
- When a user starts a new session, the user authenticates using a password; similarly, every time it is switched on, the host authenticates by presenting its keytab file. The System Security Services Daemon (SSSD) manages this process in the background.
- If the authentication is successful, the user or host obtains a Kerberos ticket granting ticket (TGT).
- The TGT is then used to obtain specific tickets for specific services.
Table 28.2. User and host session authentication
User Host Default means of authentication
Password
Keytabs
Starting a session (ordinary user)
$ kinit user_name
[switch on the host]
The result of successful authentication
TGT to be used to obtain access to specific services
TGT to be used to obtain access to specific services
TGTs and other Kerberos tickets are generated as part of the Kerberos services and policies defined by the server. The initial granting of a Kerberos ticket, the renewing of the Kerberos credentials, and even the destroying of the Kerberos session are all handled automatically by the IdM services.
28.2.3. Alternative authentication options for IdM hosts
Apart from keytabs, IdM supports two other types of machine authentication:
- SSH keys. The SSH public key for the host is created and uploaded to the host entry. From there, the System Security Services Daemon (SSSD) uses IdM as an identity provider and can work in conjunction with OpenSSH and other services to reference the public keys located centrally in IdM.
- Machine certificates. In this case, the machine uses an SSL certificate that is issued by the IdM server’s certificate authority and then stored in IdM’s Directory Server. The certificate is then sent to the machine to present when it authenticates to the server. On the client, certificates are managed by a service called certmonger.
28.3. Host entry in IdM LDAP
This section describes what a host entry in Identity Management (IdM) looks like and what attributes it can contain.
An LDAP host entry contains all relevant information about the client within IdM:
- Service entries associated with the host
- The host and service principal
- Access control rules
- Machine information, such as its physical location and operating system
Note that the IdM Web UI Identity
→ Hosts
tab does not show all the information about a particular host stored in the IdM LDAP.
28.3.1. Host entry configuration properties
A host entry can contain information about the host that is outside its system configuration, such as its physical location, MAC address, keys, and certificates.
This information can be set when the host entry is created if it is created manually. Alternatively, most of this information can be added to the host entry after the host is enrolled in the domain.
Table 28.3. Host Configuration Properties
UI Field | Command-Line Option | Description |
---|---|---|
Description |
| A description of the host. |
Locality |
| The geographic location of the host. |
Location |
| The physical location of the host, such as its data center rack. |
Platform |
| The host hardware or architecture. |
Operating system |
| The operating system and version for the host. |
MAC address |
|
The MAC address for the host. This is a multi-valued attribute. The MAC address is used by the NIS plug-in to create a NIS |
SSH public keys |
| The full SSH public key for the host. This is a multi-valued attribute, so multiple keys can be set. |
Principal name (not editable) |
|
The Kerberos principal name for the host. This defaults to the host name during the client installation, unless a different principal is explicitly set in the |
Set One-Time Password |
| This option sets a password for the host which can be used in bulk enrollment. |
- |
| This option generates a random password to be used in bulk enrollment. |
- |
| A certificate blob for the host. |
- |
| This sets whether the host can dynamically update its DNS entries if its IP address changes. |
28.4. Adding Host Entries from the Web UI
-
Open the
Identity
tab, and select theHosts
subtab. Click
at the top of the hosts list.Figure 28.1. Adding Host Entries
Enter the machine name and select the domain from the configured zones in the drop-down list. If the host has already been assigned a static IP address, then include that with the host entry so that the DNS entry is fully created.
The
Class
field has no specific purpose at the moment.Figure 28.2. Add Host Wizard
DNS zones can be created in IdM. If the IdM server does not manage the DNS server, the zone can be entered manually in the menu area, like a regular text field.
NoteSelect the
Force
check box if you want to skip checking whether the host is resolvable via DNS.Click the
Add and Edit
button to go directly to the expanded entry page and enter more attribute information. Information about the host hardware and physical location can be included with the host entry.Figure 28.3. Expanded Entry Page
Chapter 29. Managing hosts using Ansible playbooks
Ansible is an automation tool used to configure systems, deploy software, and perform rolling updates. Ansible includes support for Identity Management (IdM), and you can use Ansible modules to automate host management.
This chapter describes the following operations performed when managing hosts and host entries using Ansible playbooks:
-
Ensuring the presence of IdM host entries that are only defined by their
FQDNs
- Ensuring the presence of IdM host entries with IP addresses
- Ensuring the presence of multiple IdM host entries with random passwords
- Ensuring the presence of an IdM host entry with multiple IP addresses
- Ensuring the absence of IdM host entries
29.1. Ensuring the presence of an IdM host entry with FQDN using Ansible playbooks
This section describes ensuring the presence of host entries in Identity Management (IdM) using Ansible playbooks. The host entries are only defined by their fully-qualified domain names
(FQDNs).
Specifying the FQDN
name of the host is enough if at least one of the following conditions applies:
- The IdM server is not configured to manage DNS.
-
The host does not have a static IP address or the IP address is not known at the time the host is configured. Adding a host defined only by an
FQDN
essentially creates a placeholder entry in the IdM DNS service. For example, laptops may be preconfigured as IdM clients, but they do not have IP addresses at the time they are configured. When the DNS service dynamically updates its records, the host’s current IP address is detected and its DNS record is updated.
Without Ansible, host entries are created in IdM using the ipa host-add
command. The result of adding a host to IdM is the state of the host being present in IdM. Because of the Ansible reliance on idempotence, to add a host to IdM using Ansible, you must create a playbook in which you define the state of the host as present: state: present.
Prerequisites
- You know the IdM administrator password.
- The ansible-freeipa package is installed on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the
FQDN
of the host whose presence in IdM you want to ensure. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/host/add-host.yml
file:--- - name: Host present hosts: ipaserver become: true tasks: - name: Host host01.idm.example.com present ipahost: ipaadmin_password: MySecret123 name: host01.idm.example.com state: present force: yes
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
The procedure results in a host entry in the IdM LDAP server being created but not in enrolling the host into the IdM Kerberos realm. For that, you must deploy the host as an IdM client. For details, see Installing an Identity Management client using an Ansible playbook.
Verification steps
Log in to your IdM server as admin:
$ ssh admin@server.idm.example.com Password:
Enter the
ipa host-show
command and specify the name of the host:$ ipa host-show host01.idm.example.com Host name: host01.idm.example.com Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM Password: False Keytab: False Managed by: host01.idm.example.com
The output confirms that host01.idm.example.com exists in IdM.
29.2. Ensuring the presence of an IdM host entry with DNS information using Ansible playbooks
This section describes ensuring the presence of host entries in Identity Management (IdM) using Ansible playbooks. The host entries are defined by their fully-qualified domain names
(FQDNs) and their IP addresses.
Without Ansible, host entries are created in IdM using the ipa host-add
command. The result of adding a host to IdM is the state of the host being present in IdM. Because of the Ansible reliance on idempotence, to add a host to IdM using Ansible, you must create a playbook in which you define the state of the host as present: state: present.
Prerequisites
- You know the IdM administrator password.
- The ansible-freeipa package is installed on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the
fully-qualified domain name
(FQDN) of the host whose presence in IdM you want to ensure. In addition, if the IdM server is configured to manage DNS and you know the IP address of the host, specify a value for theip_address
parameter. The IP address is necessary for the host to exist in the DNS resource records. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/host/host-present.yml
file. You can also include other, additional information:--- - name: Host present hosts: ipaserver become: true tasks: - name: Ensure host01.idm.example.com is present ipahost: ipaadmin_password: MySecret123 name: host01.idm.example.com description: Example host ip_address: 192.168.0.123 locality: Lab ns_host_location: Lab ns_os_version: CentOS 7 ns_hardware_platform: Lenovo T61 mac_address: - "08:00:27:E3:B1:2D" - "52:54:00:BD:97:1E" state: present
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
The procedure results in a host entry in the IdM LDAP server being created but not in enrolling the host into the IdM Kerberos realm. For that, you must deploy the host as an IdM client. For details, see Installing an Identity Management client using an Ansible playbook.
Verification steps
Log in to your IdM server as admin:
$ ssh admin@server.idm.example.com Password:
Enter the
ipa host-show
command and specify the name of the host:$ ipa host-show host01.idm.example.com Host name: host01.idm.example.com Description: Example host Locality: Lab Location: Lab Platform: Lenovo T61 Operating system: CentOS 7 Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM MAC address: 08:00:27:E3:B1:2D, 52:54:00:BD:97:1E Password: False Keytab: False Managed by: host01.idm.example.com
The output confirms host01.idm.example.com exists in IdM.
29.3. Ensuring the presence of multiple IdM host entries with random passwords using Ansible playbooks
The ipahost
module allows the system administrator to ensure the presence or absence of multiple host entries in IdM using just one Ansible task. This section describes how to ensure the presence of multiple host entries that are only defined by their fully-qualified domain names
(FQDNs). Running the Ansible playbook generates random passwords for the hosts.
Without Ansible, host entries are created in IdM using the ipa host-add
command. The result of adding a host to IdM is the state of the host being present in IdM. Because of the Ansible reliance on idempotence, to add a host to IdM using Ansible, you must create a playbook in which you define the state of the host as present: state: present.
Prerequisites
- You know the IdM administrator password.
- The ansible-freeipa package is installed on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the
fully-qualified domain name
(FQDN) of the hosts whose presence in IdM you want to ensure. To make the Ansible playbook generate a random password for each host even when the host already exists in IdM andupdate_password
is limited toon_create
, add therandom: yes
andforce: yes
options. To simplify this step, you can copy and modify the example from the/usr/share/doc/ansible-freeipa/README-host.md
Markdown file:--- - name: Ensure hosts with random password hosts: ipaserver become: true tasks: - name: Hosts host01.idm.example.com and host02.idm.example.com present with random passwords ipahost: ipaadmin_password: MySecret123 hosts: - name: host01.idm.example.com random: yes force: yes - name: host02.idm.example.com random: yes force: yes register: ipahost
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-are-present.yml [...] TASK [Hosts host01.idm.example.com and host02.idm.example.com present with random passwords] changed: [r8server.idm.example.com] => {"changed": true, "host": {"host01.idm.example.com": {"randompassword": "0HoIRvjUdH0Ycbf6uYdWTxH"}, "host02.idm.example.com": {"randompassword": "5VdLgrf3wvojmACdHC3uA3s"}}}
To deploy the hosts as IdM clients using random, one-time passwords (OTPs), see Authorization options for IdM client enrollment using an Ansible playbook or Installing a client by using a one-time password: Interactive installation.
Verification steps
Log in to your IdM server as admin:
$ ssh admin@server.idm.example.com Password:
Enter the
ipa host-show
command and specify the name of one of the hosts:$ ipa host-show host01.idm.example.com Host name: host01.idm.example.com Password: True Keytab: False Managed by: host01.idm.example.com
The output confirms host01.idm.example.com exists in IdM with a random password.
29.4. Ensuring the presence of an IdM host entry with multiple IP addresses using Ansible playbooks
This section describes how to ensure the presence of a host entry in Identity Management (IdM) using Ansible playbooks. The host entry is defined by its fully-qualified domain name
(FQDN) and its multiple IP addresses.
In contrast to the ipa host
utility, the Ansible ipahost
module can ensure the presence or absence of several IPv4 and IPv6 addresses for a host. The ipa host-mod
command cannot handle IP addresses.
Prerequisites
- You know the IdM administrator password.
- The ansible-freeipa package is installed on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file. Specify, as the
name
of theipahost
variable, thefully-qualified domain name
(FQDN) of the host whose presence in IdM you want to ensure. Specify each of the multiple IPv4 and IPv6ip_address
values on a separate line by using the - ip_address syntax. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/host/host-member-ipaddresses-present.yml
file. You can also include additional information:--- - name: Host member IP addresses present hosts: ipaserver become: true tasks: - name: Ensure host101.example.com IP addresses present ipahost: ipaadmin_password: MySecret123 name: host01.idm.example.com ip_address: - 192.168.0.123 - fe80::20c:29ff:fe02:a1b3 - 192.168.0.124 - fe80::20c:29ff:fe02:a1b4 force: yes
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-with-multiple-IP-addreses-is-present.yml
The procedure creates a host entry in the IdM LDAP server but does not enroll the host into the IdM Kerberos realm. For that, you must deploy the host as an IdM client. For details, see Installing an Identity Management client using an Ansible playbook.
Verification steps
Log in to your IdM server as admin:
$ ssh admin@server.idm.example.com Password:
Enter the
ipa host-show
command and specify the name of the host:$ ipa host-show host01.idm.example.com Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM Password: False Keytab: False Managed by: host01.idm.example.com
The output confirms that host01.idm.example.com exists in IdM.
To verify that the multiple IP addresses of the host exist in the IdM DNS records, enter the
ipa dnsrecord-show
command and specify the following information:- The name of the IdM domain
The name of the host
$ ipa dnsrecord-show idm.example.com host01 [...] Record name: host01 A record: 192.168.0.123, 192.168.0.124 AAAA record: fe80::20c:29ff:fe02:a1b3, fe80::20c:29ff:fe02:a1b4
The output confirms that all the IPv4 and IPv6 addresses specified in the playbook are correctly associated with the host01.idm.example.com host entry.
29.5. Ensuring the absence of an IdM host entry using Ansible playbooks
This section describes how to ensure the absence of host entries in Identity Management (IdM) using Ansible playbooks.
Prerequisites
- IdM administrator credentials
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the
fully-qualified domain name
(FQDN) of the host whose absence from IdM you want to ensure. If your IdM domain has integrated DNS, use theupdatedns: yes
option to remove the associated records of any kind for the host from the DNS.To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/host/delete-host.yml
file:--- - name: Host absent hosts: ipaserver become: true tasks: - name: Host host01.idm.example.com absent ipahost: ipaadmin_password: MySecret123 name: host01.idm.example.com updatedns: yes state: absent
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
The procedure results in:
- The host not being present in the IdM Kerberos realm.
- The host entry not being present in the IdM LDAP server.
To remove the specific IdM configuration of system services, such as System Security Services Daemon (SSSD), from the client host itself, you must run the ipa-client-install --uninstall
command on the client. For details, see Uninstalling an IdM client.
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about host01.idm.example.com:
$ ipa host-show host01.idm.example.com ipa: ERROR: host01.idm.example.com: host not found
The output confirms that the host does not exist in IdM.
Additional resources
-
You can see the definitions of the ipahost variables as well as sample Ansible playbooks for ensuring the presence, absence, and disablement of hosts in the
/usr/share/doc/ansible-freeipa/README-host.md
Markdown file. -
Additional playbooks are in the
/usr/share/doc/ansible-freeipa/playbooks/host
directory.
Chapter 30. Managing host groups using the IdM CLI
This chapter introduces host groups in Identity Management (IdM) and describes the following operations to manage host groups and their members in the command-line interface (CLI):
- Viewing host groups and their members
- Creating host groups
- Deleting host groups
- Adding host group members
- Removing host group members
- Adding host group member managers
- Removing host group member managers
30.1. Host groups in IdM
IdM host groups can be used to centralize control over important management tasks, particularly access control.
Definition of host groups
A host group is an entity that contains a set of IdM hosts with common access control rules and other characteristics. For example, you can define host groups based on company departments, physical locations, or access control requirements.
A host group in IdM can include:
- IdM servers and clients
- Other IdM host groups
Host groups created by default
By default, the IdM server creates the host group ipaservers
for all IdM server hosts.
Direct and indirect group members
Group attributes in IdM apply to both direct and indirect members: when host group B is a member of host group A, all members of host group B are considered indirect members of host group A.
30.2. Viewing IdM host groups using the CLI
This section describes how to view IdM host groups using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
Find all host groups using the
ipa hostgroup-find
command.$ ipa hostgroup-find ------------------- 1 hostgroup matched ------------------- Host-group: ipaservers Description: IPA server hosts ---------------------------- Number of entries returned 1 ----------------------------
To display all attributes of a host group, add the
--all
option. For example:$ ipa hostgroup-find --all ------------------- 1 hostgroup matched ------------------- dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=idm,dc=local Host-group: ipaservers Description: IPA server hosts Member hosts: xxx.xxx.xxx.xxx ipauniqueid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx objectclass: top, groupOfNames, nestedGroup, ipaobject, ipahostgroup ---------------------------- Number of entries returned 1 ----------------------------
30.3. Creating IdM host groups using the CLI
This section describes how to create IdM host groups using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
Add a host group using the
ipa hostgroup-add
command.
For example, to create an IdM host group named group_name and give it a description:$ ipa hostgroup-add --desc 'My new host group' group_name --------------------- Added hostgroup "group_name" --------------------- Host-group: group_name Description: My new host group ---------------------
30.4. Deleting IdM host groups using the CLI
This section describes how to delete IdM host groups using the command-line interface (CLI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
Procedure
Delete a host group using the
ipa hostgroup-del
command.
For example, to delete the IdM host group named group_name:$ ipa hostgroup-del group_name -------------------------- Deleted hostgroup "group_name" --------------------------
Removing a group does not delete the group members from IdM.
30.5. Adding IdM host group members using the CLI
You can add hosts as well as host groups as members to an IdM host group using a single command.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
-
Optional. Use the
ipa hostgroup-find
command to find hosts and host groups.
Procedure
To add a member to a host group, use the
ipa hostgroup-add-member
and provide the relevant information. You can specify the type of member to add using these options:
Use the
--hosts
option to add one or more hosts to an IdM host group.
For example, to add the host named example_member to the group named group_name:$ ipa hostgroup-add-member group_name --hosts example_member Host-group: group_name Description: My host group Member hosts: example_member ------------------------- Number of members added 1 -------------------------
Use the
--hostgroups
option to add one or more host groups to an IdM host group.
For example, to add the host group named nested_group to the group named group_name:$ ipa hostgroup-add-member group_name --hostgroups nested_group Host-group: group_name Description: My host group Member host-groups: nested_group ------------------------- Number of members added 1 -------------------------
You can add multiple hosts and multiple host groups to an IdM host group in one single command using the following syntax:
$ ipa hostgroup-add-member group_name --hosts={host1,host2} --hostgroups={group1,group2}
When adding a host group as a member of another host group, do not create recursive groups. For example, if Group A is a member of Group B, do not add Group B as a member of Group A. Recursive groups can cause unpredictable behavior.
30.6. Removing IdM host group members using the CLI
You can remove hosts as well as host groups from an IdM host group using a single command.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
-
Optional. Use the
ipa hostgroup-find
command to confirm that the group includes the member you want to remove.
Procedure
To remove a host group member, use the
ipa hostgroup-remove-member
command and provide the relevant information. You can specify the type of member to remove using these options:
Use the
--hosts
option to remove one or more hosts from an IdM host group.
For example, to remove the host named example_member from the group named group_name:$ ipa hostgroup-remove-member group_name --hosts example_member Host-group: group_name Description: My host group ------------------------- Number of members removed 1 -------------------------
Use the
--hostgroups
option to remove one or more host groups from an IdM host group.
For example, to remove the host group named nested_group from the group named group_name:$ ipa hostgroup-remove-member group_name --hostgroups example_member Host-group: group_name Description: My host group ------------------------- Number of members removed 1 -------------------------
Removing a group does not delete the group members from IdM.
You can remove multiple hosts and multiple host groups from an IdM host group in one single command using the following syntax:
$ ipa hostgroup-remove-member group_name --hosts={host1,host2} --hostgroups={group1,group2}
30.7. Adding IdM host group member managers using the CLI
You can add hosts as well as host groups as member managers to an IdM host group using a single command. Member managers can add hosts or host groups to IdM host groups but cannot change the attributes of a host group.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
- You must have the name of the host or host group you are adding as member managers and the name of the host group you want them to manage.
Procedure
-
Optional. Use the
ipa hostgroup-find
command to find hosts and host groups. To add a member manager to a host group, use the
ipa hostgroup-add-member-manager
.For example, to add the user named example_member as a member manager to the group named group_name:
$ ipa hostgroup-add-member-manager group_name --user example_member Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins Member of netgroups: group_name Membership managed by users: example_member ------------------------- Number of members added 1 -------------------------
Use the
--groups
option to add one or more host groups as a member manager to an IdM host group.For example, to add the host group named admin_group as a member manager to the group named group_name:
$ ipa hostgroup-add-member-manager group_name --groups admin_group Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins Member of netgroups: group_name Membership managed by groups: admin_group Membership managed by users: example_member ------------------------- Number of members added 1 -------------------------
After you add a member manager to a host group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Using the
ipa group-show
command to verify the host user and host group were added as member managers.$ ipa hostgroup-show group_name Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins Membership managed by groups: admin_group Membership managed by users: example_member
Additional resources
-
See
ipa hostgroup-add-member-manager --help
for more details. -
See
ipa hostgroup-show --help
for more details.
30.8. Removing IdM host group member managers using the CLI
You can remove hosts as well as host groups as member managers from an IdM host group using a single command. Member managers can remove hosts group member managers from IdM host groups but cannot change the attributes of a host group.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- An active Kerberos ticket. For details, see Using kinit to log in to IdM manually.
- You must have the name of the existing member manager host group you are removing and the name of the host group they are managing.
Procedure
-
Optional. Use the
ipa hostgroup-find
command to find hosts and host groups. To remove a member manager from a host group, use the
ipa hostgroup-remove-member-manager
command.For example, to remove the user named example_member as a member manager from the group named group_name:
$ ipa hostgroup-remove-member-manager group_name --user example_member Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins Member of netgroups: group_name Membership managed by groups: nested_group --------------------------- Number of members removed 1 ---------------------------
Use the
--groups
option to remove one or more host groups as a member manager from an IdM host group.For example, to remove the host group named nested_group as a member manager from the group named group_name:
$ ipa hostgroup-remove-member-manager group_name --groups nested_group Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins Member of netgroups: group_name --------------------------- Number of members removed 1 ---------------------------
After you remove a member manager from a host group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
Use the
ipa group-show
command to verify that the host user and host group were removed as member managers.$ ipa hostgroup-show group_name Host-group: group_name Member hosts: server.idm.example.com Member host-groups: project_admins
Additional resources
-
See
ipa hostgroup-remove-member-manager --help
for more details. -
See
ipa hostgroup-show --help
for more details.
Chapter 31. Managing host groups using the IdM Web UI
This chapter introduces host groups in Identity Management (IdM) and describes the following operations to manage host groups and their members in the Web interface (Web UI):
- Viewing host groups and their members
- Creating host groups
- Deleting host groups
- Adding host group members
- Removing host group members
- Adding host group member managers
- Removing host group member managers
31.1. Host groups in IdM
IdM host groups can be used to centralize control over important management tasks, particularly access control.
Definition of host groups
A host group is an entity that contains a set of IdM hosts with common access control rules and other characteristics. For example, you can define host groups based on company departments, physical locations, or access control requirements.
A host group in IdM can include:
- IdM servers and clients
- Other IdM host groups
Host groups created by default
By default, the IdM server creates the host group ipaservers
for all IdM server hosts.
Direct and indirect group members
Group attributes in IdM apply to both direct and indirect members: when host group B is a member of host group A, all members of host group B are considered indirect members of host group A.
31.2. Viewing host groups in the IdM Web UI
This section describes how to view IdM host groups using the Web interface (Web UI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
Click Identity → Groups, and select the Host Groups tab.
- The page lists the existing host groups and their descriptions.
- You can search for a specific host group.
Click on a group in the list to display the hosts that belong to this group. You can limit results to direct or indirect members.
Select the Host Groups tab to display the host groups that belong to this group (nested host groups). You can limit results to direct or indirect members.
31.3. Creating host groups in the IdM Web UI
This section describes how to create IdM host groups using the Web interface (Web UI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Click Identity → Groups, and select the Host Groups tab.
- Click Add. The Add host group dialog appears.
- Provide the information about the group: name (required) and description (optional).
Click Add to confirm.
31.4. Deleting host groups in the IdM Web UI
This section describes how to delete IdM host groups using the Web interface (Web UI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Click Identity → Groups and select the Host Groups tab.
- Select the IdM host group to remove, and click Delete. A confirmation dialog appears.
Click Delete to confirm
Removing a host group does not delete the group members from IdM.
31.5. Adding host group members in the IdM Web UI
This section describes how to add host group members in IdM using the web interface (Web UI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Click Identity → Groups and select the Host Groups tab.
- Click the name of the group to which you want to add members.
- Click the tab Hosts or Host groups depending on the type of members you want to add. The corresponding dialog appears.
- Select the hosts or host groups to add, and click the > arrow button to move them to the Prospective column.
Click Add to confirm.
31.6. Removing host group members in the IdM Web UI
This section describes how to remove host group members in IdM using the web interface (Web UI).
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
Procedure
- Click Identity → Groups and select the Host Groups tab.
- Click the name of the group from which you want to remove members.
- Click the tab Hosts or Host groups depending on the type of members you want to remove.
- Select the check box next to the member you want to remove.
Click Delete. A confirmation dialog appears.
- Click Delete to confirm. The selected members are deleted.
31.7. Adding IdM host group member managers using the Web UI
This section describes how to add users or user groups as host group member managers in IdM using the web interface (Web UI). Member managers can add hosts group member managers to IdM host groups but cannot change the attributes of a host group.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
- You must have the name of the host group you are adding as member managers and the name of the host group you want them to manage.
Procedure
Click Identity → Groups and select the Host Groups tab.
- Click the name of the group to which you want to add member managers.
- Click the member managers tab User Groups or Users depending on the type of member managers you want to add. The corresponding dialog appears.
Click Add.
- Select the users or user groups to add, and click the > arrow button to move them to the Prospective column.
- Click Add to confirm.
After you add a member manager to a host group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
On the Host Group dialog, verify the user group or user has been added to the member managers list of groups or users.
31.8. Removing IdM host group member managers using the Web UI
This section describes how to remove users or user groups as host group member managers in IdM using the web interface (Web UI). Member managers can remove hosts group member managers from IdM host groups but cannot change the attributes of a host group.
Prerequisites
- Administrator privileges for managing IdM or User Administrator role.
- You are logged-in to the IdM Web UI. For details, see Accessing the IdM Web UI in a web browser.
- You must have the name of the existing member manager host group you are removing and the name of the host group they are managing.
Procedure
Click Identity → Groups and select the Host Groups tab.
- Click the name of the group from which you want to remove member managers.
- Click the member managers tab User Groups or Users depending on the type of member managers you want to remove. The corresponding dialog appears.
- Select the user or user groups to remove and click Delete.
Click Delete to confirm.
NoteAfter you remove a member manager from a host group, the update may take some time to spread to all clients in your Identity Management environment.
Verification steps
On the Host Group dialog, verify the user group or user has been removed from the member managers list of groups or users.
Chapter 32. Managing host groups using Ansible playbooks
This chapter describes using Ansible to perform the following operations involving host groups in Identity Management (IdM):
- Ensuring the presence of IdM host groups
- Ensuring the presence of hosts in IdM host groups
- Nesting IdM host groups
- Ensuring the presence of member managers in IdM host groups
- Ensuring the absence of hosts from IdM host groups
- Ensuring the absence of nested host groups from IdM host groups
- Ensuring the absence of member managers from IdM host groups
32.1. Ensuring the presence of IdM host groups using Ansible playbooks
This section describes how to ensure the presence of host groups in Identity Management (IdM) using Ansible playbooks.
Without Ansible, host group entries are created in IdM using the ipa hostgroup-add
command. The result of adding a host group to IdM is the state of the host group being present in IdM. Because of the Ansible reliance on idempotence, to add a host group to IdM using Ansible, you must create a playbook in which you define the state of the host group as present: state: present.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host group information. For example, to ensure the presence of a host group named databases, specify
name: databases
in the- ipahostgroup
task. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-present.yml
file.--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: # Ensure host-group databases is present - ipahostgroup: ipaadmin_password: MySecret123 name: databases state: present
In the playbook, state: present signifies a request to add the host group to IdM unless it already exists there.
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-present.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about the host group whose presence in IdM you wanted to ensure:
$ ipa hostgroup-show databases Host-group: databases
The databases host group exists in IdM.
32.2. Ensuring the presence of hosts in IdM host groups using Ansible playbooks
This section describes how to ensure the presence of hosts in host groups in Identity Management (IdM) using Ansible playbooks.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- The hosts you want to reference in your Ansible playbook exist in IdM. For details, see Ensuring the presence of an IdM host entry using Ansible playbooks.
- The host groups you reference from the Ansible playbook file have been added to IdM. For details, see Ensuring the presence of IdM host groups using Ansible playbooks.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host information. Specify the name of the host group using the
name
parameter of theipahostgroup
variable. Specify the name of the host with thehost
parameter of theipahostgroup
variable. To simplify this step, you can copy and modify the examples in the/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml
file:--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: # Ensure host-group databases is present - ipahostgroup: ipaadmin_password: MySecret123 name: databases host: - db.idm.example.com action: member
This playbook adds the db.idm.example.com host to the databases host group. The
action: member
line indicates that when the playbook is run, no attempt is made to add the databases group itself. Instead, only an attempt is made to add db.idm.example.com to databases.Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about a host group to see which hosts are present in it:
$ ipa hostgroup-show databases Host-group: databases Member hosts: db.idm.example.com
The db.idm.example.com host is present as a member of the databases host group.
32.3. Nesting IdM host groups using Ansible playbooks
This section describes ensuring the presence of nested host groups in Identity Management (IdM) host groups using Ansible playbooks.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- The host groups you reference from the Ansible playbook file exist in IdM. For details, see Ensuring the presence of IdM host groups using Ansible playbooks.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host group information. To ensure that a nested host group A exists in a host group B: in the Ansible playbook, specify, among the
- ipahostgroup
variables, the name of the host group B using thename
variable. Specify the name of the nested hostgroup A with thehostgroup
variable. To simplify this step, you can copy and modify the examples in the/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml
file:--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: # Ensure hosts and hostgroups are present in existing databases hostgroup - ipahostgroup: ipaadmin_password: MySecret123 name: databases hostgroup: - mysql-server - oracle-server action: member
This Ansible playbook ensures the presence of the myqsl-server and oracle-server host groups in the databases host group. The
action: member
line indicates that when the playbook is run, no attempt is made to add the databases group itself to IdM.Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about the host group in which nested host groups are present:
$ ipa hostgroup-show databases Host-group: databases Member hosts: db.idm.example.com Member host-groups: mysql-server, oracle-server
The mysql-server and oracle-server host groups exist in the databases host group.
32.4. Ensuring the presence of member managers in IDM host groups using Ansible Playbooks
The following procedure describes ensuring the presence of member managers in IdM hosts and host groups using an Ansible playbook.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- You must have the name of the host or host group you are adding as member managers and the name of the host group you want them to manage.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host and host group member management information:
--- - name: Playbook to handle host group membership management hosts: ipaserver become: true tasks: - name: Ensure member manager user example_member is present for group_name ipahostgroup: ipaadmin_password: MySecret123 name: group_name membermanager_user: example_member - name: Ensure member manager group project_admins is present for group_name ipahostgroup: ipaadmin_password: MySecret123 name: group_name membermanager_group: project_admins
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-host-groups.yml
Verification steps
You can verify if the group_name group contains example_member and project_admins as member managers by using the ipa group-show
command:
Log into
ipaserver
as administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about testhostgroup:
ipaserver]$ ipa hostgroup-show group_name Host-group: group_name Member hosts: server.idm.example.com Member host-groups: testhostgroup2 Membership managed by groups: project_admins Membership managed by users: example_member
Additional resources
-
See
ipa hostgroup-add-member-manager --help
. -
See the
ipa
man page.
32.5. Ensuring the absence of hosts from IdM host groups using Ansible playbooks
This section describes how to ensure the absence of hosts from host groups in Identity Management (IdM) using Ansible playbooks.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- The hosts you want to reference in your Ansible playbook exist in IdM. For details, see Ensuring the presence of an IdM host entry using Ansible playbooks.
- The host groups you reference from the Ansible playbook file exist in IdM. For details, see Ensuring the presence of IdM host groups using Ansible playbooks.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host and host group information. Specify the name of the host group using the
name
parameter of theipahostgroup
variable. Specify the name of the host whose absence from the host group you want to ensure using thehost
parameter of theipahostgroup
variable. To simplify this step, you can copy and modify the examples in the/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml
file:--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: # Ensure host-group databases is absent - ipahostgroup: ipaadmin_password: MySecret123 name: databases host: - db.idm.example.com action: member state: absent
This playbook ensures the absence of the db.idm.example.com host from the databases host group. The action: member line indicates that when the playbook is run, no attempt is made to remove the databases group itself.
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about the host group and the hosts it contains:
$ ipa hostgroup-show databases Host-group: databases Member host-groups: mysql-server, oracle-server
The db.idm.example.com host does not exist in the databases host group.
32.6. Ensuring the absence of nested host groups from IdM host groups using Ansible playbooks
This section describes how to ensure the absence of nested host groups from outer host groups in Identity Management (IdM) using Ansible playbooks.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- The host groups you reference from the Ansible playbook file exist in IdM. For details, see Ensuring the presence of IdM host groups using Ansible playbooks.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host group information. Specify, among the
- ipahostgroup
variables, the name of the outer host group using thename
variable. Specify the name of the nested hostgroup with thehostgroup
variable. To simplify this step, you can copy and modify the examples in the/usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml
file:--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: # Ensure hosts and hostgroups are absent in existing databases hostgroup - ipahostgroup: ipaadmin_password: MySecret123 name: databases hostgroup: - mysql-server - oracle-server action: member state: absent
This playbook makes sure that the mysql-server and oracle-server host groups are absent from the databases host group. The
action: member
line indicates that when the playbook is run, no attempt is made to ensure the databases group itself is deleted from IdM.Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about the host group from which nested host groups should be absent:
$ ipa hostgroup-show databases Host-group: databases
The output confirms that the mysql-server and oracle-server nested host groups are absent from the outer databases host group.
32.7. Ensuring the absence of IdM host groups using Ansible playbooks
This section describes how to ensure the absence of host groups in Identity Management (IdM) using Ansible playbooks.
Without Ansible, host group entries are removed from IdM using the ipa hostgroup-del
command. The result of removing a host group from IdM is the state of the host group being absent from IdM. Because of the Ansible reliance on idempotence, to remove a host group from IdM using Ansible, you must create a playbook in which you define the state of the host group as absent: state: absent.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it with the list of IdM servers to target:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host group information. To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-absent.yml
file.--- - name: Playbook to handle hostgroups hosts: ipaserver become: true tasks: - Ensure host-group databases is absent ipahostgroup: ipaadmin_password: MySecret123 name: databases state: absent
This playbook ensures the absence of the databases host group from IdM. The
state: absent
means a request to delete the host group from IdM unless it is already deleted.Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-absent.yml
Verification steps
Log into
ipaserver
as admin:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Request a Kerberos ticket for admin:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
Display information about the host group whose absence you ensured:
$ ipa hostgroup-show databases ipa: ERROR: databases: host group not found
The databases host group does not exist in IdM.
32.8. Ensuring the absence of member managers from IdM host groups using Ansible playbooks
The following procedure describes ensuring the absence of member managers in IdM hosts and host groups using an Ansible playbook.
Prerequisites
- You know the IdM administrator password.
- You have installed the ansible-freeipa package on the Ansible controller.
- You must have the name of the user or user group you are removing as member managers and the name of the host group they are managing.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create an Ansible playbook file with the necessary host and host group member management information:
--- - name: Playbook to handle host group membership management hosts: ipaserver become: true tasks: - name: Ensure member manager host and host group members are absent for group_name ipahostgroup: ipaadmin_password: MySecret123 name: group_name membermanager_user: example_member membermanager_group: project_admins action: member state: absent
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-host-groups-are-absent.yml
Verification steps
You can verify if the group_name group does not contain example_member or project_admins as member managers by using the ipa group-show
command:
Log into
ipaserver
as administrator:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Display information about testhostgroup:
ipaserver]$ ipa hostgroup-show group_name Host-group: group_name Member hosts: server.idm.example.com Member host-groups: testhostgroup2
Additional resources
-
See
ipa hostgroup-add-member-manager --help
. -
See the
ipa
man page.
Chapter 33. Managing Kerberos ticket policies
Kerberos ticket policies in Identity Management (IdM) set restrictions on Kerberos ticket access, duration, and renewal. You can configure Kerberos ticket policies for the Key Distribution Center (KDC) running on your IdM server.
This chapter presents the following Kerberos ticket management topics and tasks:
- The role of the IdM KDC
- IdM Kerberos ticket policy types
- Kerberos authentication indicators
- Enforcing authentication indicators for an IdM service
- Configuring the global ticket lifecycle policy
- Configuring global ticket policies per authentication indicator
- Configuring the default ticket policy for a user
- Configuring individual authentication indicator ticket policies for a user
-
Authentication indicator options for the
krbtpolicy-mod
command
33.1. The role of the IdM KDC
Identity Management’s authentication mechanisms use the Kerberos infrastructure established by the Key Distribution Center (KDC). The KDC is the trusted authority that stores credential information and ensures the authenticity of data originating from entities within the IdM network.
Each IdM user, service, and host acts as a Kerberos client and is identified by a unique Kerberos principal:
-
For users:
identifier@REALM
, such asadmin@EXAMPLE.COM
-
For services:
service/fully-qualified-hostname@REALM
, such ashttp/master.example.com@EXAMPLE.COM
-
For hosts:
host/fully-qualified-hostname@REALM
, such ashost/client.example.com@EXAMPLE.COM
The following image is a simplification of the communication between a Kerberos client, the KDC, and a Kerberized application that the client wants to communicate with.

-
A Kerberos client identifies itself to the KDC by authenticating as a Kerberos principal. For example, an IdM user performs
kinit username
and provides their password. - The KDC checks for the principal in its database, authenticates the client, and evaluates Kerberos ticket policies to determine whether to grant the request.
- The KDC issues the client a ticket-granting ticket (TGT) with a lifecycle and authentication indicators according to the appropriate ticket policy.
- With the TGT, the client requests a service ticket from the KDC to communicate with a Kerberized service on a target host.
- The KDC checks if the client’s TGT is still valid, and evaluates the service ticket request against ticket policies.
- The KDC issues the client a service ticket.
- With the service ticket, the client can initiate encrypted communication with the service on the target host.
33.2. IdM Kerberos ticket policy types
IdM Kerberos ticket policies implement the following ticket policy types:
- Connection policy
To protect Kerberized services with different levels of security, you can define connection policies to enforce rules based on which pre-authentication mechanism a client used to retrieve a ticket-granting ticket (TGT).
For example, you can require smart card authentication to connect to
client1.example.com
, and require two-factor authentication to access thetestservice
application onclient2.example.com
.To enforce connection policies, associate authentication indicators with services. Only clients that have the required authentication indicators in their service ticket requests are able to access those services. For more information, see Kerberos authentication indicators.
- Ticket lifecycle policy
Each Kerberos ticket has a lifetime and a potential renewal age: you can renew a ticket before it reaches its maximum lifetime, but not after it exceeds its maximum renewal age.
The default global ticket lifetime is one day (86400 seconds) and the default global maximum renewal age is one week (604800 seconds). To adjust these global values, see Configuring the global ticket lifecycle policy.
You can also define your own ticket lifecycle policies:
- To configure different global ticket lifecycle values for each authentication indicator, see Configuring global ticket policies per authentication indicator.
- To define ticket lifecycle values for a single user that apply regardless of the authentication method used, see Configuring the default ticket policy for a user.
- To define individual ticket lifecycle values for each authentication indicator that only apply to a single user, see Configuring individual authentication indicator ticket policies for a user.
33.3. Kerberos authentication indicators
The Kerberos Key Distribution Center (KDC) attaches authentication indicators to a ticket-granting ticket (TGT) based on which pre-authentication mechanism the client used prove its identity:
otp
- two-factor authentication (password + One-Time Password)
radius
- RADIUS authentication (commonly for 802.1x authentication)
pkinit
- PKINIT, smart card, or certificate authentication
hardened
- hardened passwords (SPAKE or FAST)[1]
The KDC then attaches the authentication indicators from the TGT to any service ticket requests that stem from it. The KDC enforces policies such as service access control, maximum ticket lifetime, and maximum renewable age based on the authentication indicators.
33.3.1. Authentication indicators and IdM services
If you associate a service or a host with an authentication indicator, only clients that used the corresponding authentication mechanism to obtain a TGT will be able to access it. The KDC, not the application or service, checks for authentication indicators in service ticket requests, and grants or denies requests based on Kerberos connection policies.
For example, to require two-factor authentication to connect to host secure.example.com
, associate the otp
authentication indicator with the host/secure.example.com@EXAMPLE.COM
Kerberos principal. Only users who used a One-Time password to obtain their initial TGT from the KDC will be able to log in.
If a service or a host has no authentication indicators assigned to it, it will accept tickets authenticated by any mechanism.
Additional resources
- To associate an IdM service with authentication indicators, see Enforcing authentication indicators for an IdM service.
33.4. Enforcing authentication indicators for an IdM service
This procedure describes creating an IdM service and configuring it to require particular Kerberos authentication indicators from incoming service ticket requests.
By associating authentication indicators with an IdM service, only clients who used those specific pre-authentication mechanisms to obtain their initial ticket-granting ticket (TGT) will be able to access the service.
33.4.1. Creating an IdM service entry and its Kerberos keytab
Adding an IdM service entry to IdM for a service running on an IdM host creates a corresponding Kerberos principal, and allows the service to request an SSL certificate, a Kerberos keytab, or both.
The following procedure describes creating an IdM service entry and generating an associated Kerberos keytab for encrypting communication with that service.
Prerequisites
- Your service can store a Kerberos principal, an SSL certificate, or both.
Procedure
Add an IdM service with the
ipa service-add
command to create a Kerberos principal associated with it. For example, to create the IdM service entry for thetestservice
application that runs on hostclient.example.com
:[root@client ~]# ipa service-add testservice/client.example.com ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Managed by: client.example.com
Generate and store a Kerberos keytab for the service on the client.
[root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com Keytab successfully retrieved and stored in: /etc/testservice.keytab
Verification steps
Display information about an IdM service with the
ipa service-show
command.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Keytab: True Managed by: client.example.com
Display the contents of the service’s Kerberos keytab with the
klist
command.[root@server etc]# klist -ekt /etc/testservice.keytab Keytab name: FILE:/etc/testservice.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac) 2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)
33.4.2. Associating authentication indicators with an IdM service
This procedure describes configuring a service to require particular Kerberos authentication indicators from incoming service ticket requests.
Prerequisites
- You have created an IdM service entry for a service that runs on an IdM host. See Creating an IdM service entry and its Kerberos keytab.
Do not assign authentication indicators to internal IdM services. The following IdM services cannot perform the interactive authentication steps required by PKINIT and multi-factor authentication methods:
host/server.example.com@EXAMPLE.COM HTTP/server.example.com@EXAMPLE.COM ldap/server.example.com@EXAMPLE.COM DNS/server.example.com@EXAMPLE.COM cifs/server.example.com@EXAMPLE.COM
Procedure
Use the
ipa service-mod
command to specify one or more required authentication indicators for a service, identified with the--auth-ind
argument.Authentication method --auth-ind
valueTwo-factor authentication
otp
RADIUS authentication
radius
PKINIT, smart card, or certificate authentication
pkinit
Hardened passwords (SPAKE or FAST)
hardened
For example, to require that a user was authenticated with smart card or OTP authentication to retrieve a service ticket for the
testservice
principal on hostclient.example.com
:[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit ------------------------------------------------------------- Modified service "testservice/client.example.com@EXAMPLE.COM" ------------------------------------------------------------- Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Managed by: client.example.com
To remove all authentication indicators from a service, provide an empty list of indicators:
[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
Principal name: testservice/client.example.com@EXAMPLE.COM
Principal alias: testservice/client.example.com@EXAMPLE.COM
Managed by: client.example.com
Verification steps
Display information about an IdM service, including the authentication indicators it requires, with the
ipa service-show
command.[root@server ~]# ipa service-show testservice/client.example.com Principal name: testservice/client.example.com@EXAMPLE.COM Principal alias: testservice/client.example.com@EXAMPLE.COM Authentication Indicators: otp, pkinit Keytab: True Managed by: client.example.com
Additional resources
- To test requesting a service ticket for an IdM service, see Retrieving a Kerberos service ticket for an IdM service.
33.4.3. Retrieving a Kerberos service ticket for an IdM service
The following procedure describes retrieving a Kerberos service ticket for an IdM service. You can use this procedure to test Kerberos ticket policies.
Prerequisites
- If the service you are working with is not an internal IdM service, you have created a corresponding IdM service entry for it. See Creating an IdM service entry and its Kerberos keytab.
- You have a Kerberos ticket-granting ticket (TGT).
Procedure
Use the
kvno
command with the-S
option to retrieve a service ticket, and specify the name of the IdM service and the fully-qualified domain name of the host that manages it.[root@server ~]# kvno -S testservice client.example.com testservice/client.example.com@EXAMPLE.COM: kvno = 1
If you need to access an IdM service and your current ticket-granting ticket (TGT) does not possess the required authentication indicators associated with it, clear your current Kerberos credentials cache with the kdestroy
command and retrieve a new TGT:
[root@server ~]# kdestroy
For example, if you initially retrieved a TGT by authenticating with a password, and you need to access an IdM service that has the pkinit
authentication indicator associated with it, destroy your current credentials cache and re-authenticate with a smart card. See Kerberos authentication indicators.
Verification steps
Use the
klist
command to verify that the service ticket is in the default Kerberos credentials cache.[root@server etc]# klist_ Ticket cache: KCM:1000 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 04/01/2020 12:52:42 04/02/2020 12:52:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM 04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM
33.4.4. Additional resources
- For more information on Kerberos authentication indicators, see Section 33.3, “Kerberos authentication indicators”.
33.5. Configuring the global ticket lifecycle policy
The global ticket policy applies to all service tickets and to users that do not have any per-user ticket policies defined.
The following procedure describes adjusting the maximum ticket lifetime and maximum ticket renewal age for the global Kerberos ticket policy using the ipa krbtpolicy-mod
command.
While using the ipa krbtpolicy-mod
command, specify at least one of the following arguments:
-
--maxlife
for the maximum ticket lifetime in seconds -
--maxrenew
for the maximum renewable age in seconds
Procedure
To modify the global ticket policy:
[root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60)) Max life: 28800 Max renew: 86400
In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).
Optional: To reset the global Kerberos ticket policy to the default installation values:
[root@server ~]# ipa krbtpolicy-reset Max life: 86400 Max renew: 604800
Verification steps
Display the global ticket policy:
[root@server ~]# ipa krbtpolicy-show Max life: 28800 Max renew: 86640
Additional resources
- To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To configure individual ticket policies for each authentication indicator for a single user, see Configuring individual authentication indicator ticket policies for a user.
33.6. Configuring global ticket policies per authentication indicator
This procedure describes adjusting the global maximum ticket lifetime and maximum renewable age for each authentication indicator. These settings apply to users that do not have per-user ticket policies defined.
Use the ipa krbtpolicy-mod
command to specify the global maximum lifetime or maximum renewable age for Kerberos tickets depending on the authentication indicators attached to them.
Procedure
For example, to set the global two-factor ticket lifetime and renewal age values to one week, and the global smart card ticket lifetime and renewal age values to two weeks:
[root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800
Verification steps
Display the global ticket policy:
[root@server ~]# ipa krbtpolicy-show Max life: 86400 OTP max life: 604800 PKINIT max life: 172800 Max renew: 604800 OTP max renew: 604800 PKINIT max renew: 172800
Notice that the OTP and PKINIT values are different from the global default
Max life
andMax renew
values.
Additional resources
-
For a list of authentication indicator options for the
ipa krbtpolicy-mod
command, see Authentication indicator options for thekrbtpolicy-mod
command. - To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To configure individual ticket policies for each authentication indicator for a single user, see Configuring individual authentication indicator ticket policies for a user.
33.7. Configuring the default ticket policy for a user
You can define a unique Kerberos ticket policy that only applies to a single user. These per-user settings override the global ticket policy, for all authentication indicators.
Use the ipa krbtpolicy-mod username
command, and specify at least one of the following arguments:
-
--maxlife
for the maximum ticket lifetime in seconds -
--maxrenew
for the maximum renewable age in seconds
Procedure
For example, to set the IdM
admin
user’s maximum ticket lifetime to two days and maximum renewal age to two weeks:[root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600 Max life: 172800 Max renew: 1209600
Optional: To reset the ticket policy for a user:
[root@server ~]# ipa krbtpolicy-reset admin
Verification steps
Display the effective Kerberos ticket policy that applies to a user:
[root@server ~]# ipa krbtpolicy-show admin Max life: 172800 Max renew: 1209600
Additional resources
- To adjust the global ticket policy for all users, see Configuring the global ticket lifecycle policy.
- To configure different default ticket policies per authentication indicator, see Configuring global ticket policies per authentication indicator.
33.8. Configuring individual authentication indicator ticket policies for a user
As an administrator, you can define Kerberos ticket policies for a user that differ per authentication indicator. For example, you can configure a policy to allow the IdM admin
user to renew a ticket for two days if it was obtained with OTP authentication, and a week if it was obtained with smart card authentication.
These per-authentication indicator settings will override the user’s default ticket policy, the global default ticket policy, and any global authentication indicator ticket policy.
Use the ipa krbtpolicy-mod username
command to set custom maximum lifetime and maximum renewable age values for a user’s Kerberos tickets depending on the authentication indicators attached to them.
Procedure
For example, to allow the IdM
admin
user to renew a Kerberos ticket for two days if it was obtained with One-Time Password authentication, set the--otp-maxrenew
option:[root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60)) OTP max renew: 172800
Optional: To reset the ticket policy for a user:
[root@server ~]# ipa krbtpolicy-reset username
Verification steps
Display the effective Kerberos ticket policy that applies to a user:
[root@server ~]# ipa krbtpolicy-show admin Max life: 28800 Max renew: 86640
Additional resources
-
For a list of authentication indicator options for the
ipa krbtpolicy-mod
command, see Authentication indicator options for thekrbtpolicy-mod
command. - To adjust the default ticket policy for a single user, see Configuring the default ticket policy for a user.
- To adjust the global ticket policy for all users, see Configuring the global ticket lifecycle policy.
- To configure different global ticket policies per authentication indicator, see Configuring global ticket policies per authentication indicator.
33.9. Authentication indicator options for the krbtpolicy-mod
command
Specify values for authentication indicators with the following arguments.
Table 33.1. Authentication indicator options for the krbtpolicy-mod
command
Authentication indicator | Argument for maximum lifetime | Argument for maximum renewal age |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Chapter 34. Defining IdM Password Policies
This chapter describes Identity Management (IdM) password policies and how to add a new password policy in IdM using an Ansible playbook.
34.1. What is a password policy
A password policy is a set of rules that passwords must meet. For example, a password policy can define the minimum password length and the maximum password lifetime. All users affected by this policy are required to set a sufficiently long password and change it frequently enough to meet the specified conditions. In this way, password policies help reduce the risk of someone discovering and misusing a user’s password.
34.2. Password policies in IdM
Passwords are the most common way for Identity Management (IdM) users to authenticate to the IdM Kerberos domain. Password policies define the requirements that these IdM user passwords must meet.
The IdM password policy is set in the underlying LDAP directory, but the Kerberos Key Distribution Center (KDC) enforces the password policy.
Password policy attributes lists the attributes you can use to define a password policy in IdM.
Table 34.1. Password Policy Attributes
Attribute | Explanation | Example |
---|---|---|
Max lifetime | The maximum amount of time in days that a password is valid before a user must reset it. | Max lifetime = 90 User passwords are valid only for 90 days. After that, IdM prompts users to change them. |
Min lifetime | The minimum amount of time in hours that must pass between two password change operations. | Min lifetime = 1 After users change their passwords, they must wait at least 1 hour before changing them again. |
History size | The number of previous passwords that are stored. A user cannot reuse a password from their password history but can reuse old passwords that are not stored. | History size = 0 In this case, the password history is empty and users can reuse any of their previous passwords. |
Character classes | The number of different character classes the user must use in the password. The character classes are: * Uppercase characters * Lowercase characters * Digits * Special characters, such as comma (,), period (.), asterisk (*) * Other UTF-8 characters Using a character three or more times in a row decreases the character class by one. For example:
*
* | Character classes = 0
The default number of classes required is 0. To configure the number, run the See also the Important note below this table. |
Min length | The minimum number of characters in a password. | Min length = 8 Users cannot use passwords shorter than 8 characters. |
Max failures | The maximum number of failed login attempts before IdM locks the user account. | Max failures = 6 IdM locks the user account when the user enters a wrong password 7 times in a row. |
Failure reset interval | The amount of time in seconds after which IdM resets the current number of failed login attempts. | Failure reset interval = 60
If the user waits for more than 1 minute after the number of failed login attempts defined in |
Lockout duration |
The amount of time in seconds that the user account is locked after the number of failed login attempts defined in | Lockout duration = 600 Users with locked accounts are unable to log in for 10 minutes. |
Use the English alphabet and common symbols for the character classes requirement if you have a diverse set of hardware that may not have access to international characters and symbols. For more information about character class policies in passwords, see What characters are valid in a password? in Red Hat Knowledgebase.
34.3. Ensuring the presence of a password policy in IdM using an Ansible playbook
This section describes how to ensure the presence of a password policy in Identity Management (IdM) using an Ansible playbook.
In the default global_policy
password policy in IdM, the number of different character classes in the password is set to 0. The history size is also set to 0.
Complete this procedure to enforce a stronger password policy for an IdM group using an Ansible playbook.
You can only define a password policy for an IdM group. You cannot define a password policy for an individual user.
Prerequisites
- You have installed the ansible-freeipa package on the Ansible controller.
- You know the IdM administrator password.
- The group for which you are ensuring the presence of a password policy exists in IdM.
Procedure
Create an inventory file, for example
inventory.file
, and define theFQDN
of your IdM server in the[ipaserver]
section:[ipaserver] server.idm.example.com
Create your Ansible playbook file that defines the password policy whose presence you want to ensure. To simplify this step, copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml
file:--- - name: Tests hosts: ipaserver become: true tasks: - name: Ensure presence of pwpolicy for group ops ipapwpolicy: ipaadmin_password: MySecret123 name: ops minlife: 7 maxlife: 49 history: 5 priority: 1 lockouttime: 300 minlength: 8 minclasses: 4 maxfail: 3 failinterval: 5
For details on what the individual variables mean, see Password policy attributes.
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml
You have successfully used an Ansible playbook to ensure that a password policy for the ops group is present in IdM.
The priority of the ops password policy is set to 1, whereas the global_policy password policy has no priority set. For this reason, the ops policy automatically supersedes global_policy for the ops group and is enforced immediately.
global_policy serves as a fallback policy when no group policy is set for a user, and it can never take precedence over a group policy.
Additional resources
-
For more details about using Ansible to define password policies in IdM and about playbook variables, see the README-pwpolicy.md Markdown file available in the
/usr/share/doc/ansible-freeipa/
directory. - For more details about how password policy priorities work in IdM, see Password policy priorities in RHEL 7 documentation.
Chapter 35. Managing expiring password notifications
You can use the Expiring Password Notification (EPN) tool, provided by the ipa-client-epn
package, to build a list of Identity Management (IdM) users whose passwords are expiring in a configured amount of time. To install, configure, and use the EPN tool, refer to the relevant sections.
- What is the Expiring Password Notification tool
- Installing the Expiring Password Notification tool
- Running the EPN tool to send emails to users whose passwords are expiring
- Enabling the ipa-epn.timer to send an email to all users whose passwords are expiring
- Modifying the Expiring Password Notification email template
35.1. What is the Expiring Password Notification tool
The Expiring Password Notification (EPN) tool is a standalone tool you can use to build a list of Identity Management (IdM) users whose passwords are expiring in a configured amount of time.
IdM administrators can use EPN to:
- Display a list of affected users in JSON format, which is created when run in dry-run mode.
- Calculate how many emails will be sent for a given day or date range.
- Send password expiration email notifications to users.
-
Configure the
ipa-epn.timer
to run the EPN tool daily and send an email to users whose passwords are expiring within the defined future date ranges. - Customize the email notification to send to users.
If a user account is disabled, no email notifications are sent if the password is going to expire.
35.2. Installing the Expiring Password Notification tool
This procedure describes how to install the Expiring Password Notification (EPN) tool.
Prerequisites
- Install the EPN tool on either an Identity Management (IdM) replica or an IdM client with a local Postfix SMTP server configured as a smart host.
Procedure
Install the EPN tool:
# dnf install ipa-client-epn
35.3. Running the EPN tool to send emails to users whose passwords are expiring
This procedure describes how to run the Expiring Password Notification (EPN) tool to send emails to users whose passwords are expiring.
The EPN tool is stateless. If the EPN tool fails to email any of the users whose passwords are expiring on a given day, the EPN tool does not save a list of those users.
Prerequisites
-
The
ipa-client-epn
package is installed. See Installing the Expiring Password Notification tool. -
Customize the
ipa-epn
email template if required. See Modifying the Expiring Password Notification email template.
Procedure
Update the
epn.conf
configuration file to set the options for the EPN tool to notify users of upcoming password expiration.# vi /etc/ipa/epn.conf
Update the
notify_ttls
as required. The default is to notify users whose passwords are expiring in 28, 14, 7, 3, and 1 day(s).notify_ttls = 28, 14, 7, 3, 1
Configure your SMTP server and port:
smtp_server = localhost smtp_port = 25
Specify the email address from which the email expiration notification is sent. Any unsuccessfully delivered emails are returned to this address.
mail_from =admin-email@example.com
-
Save the
/etc/ipa/epn.conf
file. Run the EPN tool in dry-run mode to generate a list of the users to whom the password expiration email notification would be sent if you run the tool without the
--dry-run
option.ipa-epn --dry-run [ { "uid": "user5", "cn": "user 5", "krbpasswordexpiration": "2020-04-17 15:51:53", "mail": "['user5@ipa.test']" } ] [ { "uid": "user6", "cn": "user 6", "krbpasswordexpiration": "2020-12-17 15:51:53", "mail": "['user5@ipa.test']" } ] The IPA-EPN command was successful
NoteIf the list of users returned is very large and you run the tool without the
--dry-run
option, this might cause an issue with your email server.Run the EPN tool without the
--dry-run
option to send expiration emails to the list of all the users returned when you ran the EPN tool in dry-run mode:ipa-epn [ { "uid": "user5", "cn": "user 5", "krbpasswordexpiration": "2020-10-01 15:51:53", "mail": "['user5@ipa.test']" } ] [ { "uid": "user6", "cn": "user 6", "krbpasswordexpiration": "2020-12-17 15:51:53", "mail": "['user5@ipa.test']" } ] The IPA-EPN command was successful
You can add EPN to any monitoring system and invoke it with the
--from-nbdays
and--to-nbdays
options to determine how many users passwords are going to expire within a specific time frame:# ipa-epn --from-nbdays 8 --to-nbdays 12
NoteIf you invoke the EPN tool with the
--from-nbdays
and--to-nbdays
options, it is automatically executed in dry-run mode.
Verification steps
- Run the EPN tool and verify an email notification is sent.
Additional resources
-
See
ipa-epn
man page. -
See
epn.conf
man page.
35.4. Enabling the ipa-epn.timer to send an email to all users whose passwords are expiring
This procedure describes how to use ipa-epn.timer
to run the Expiring Password Notification (EPN) tool to send emails to users whose passwords are expiring. The ipa-epn.timer
parses the epn.conf
file and sends an email to users whose passwords are expiring within the defined future date ranges configured in that file.
Prerequisites
-
The
ipa-client-epn
package is installed. See Installing the Expiring Password Notification tool -
Customize the
ipa-epn
email template if required. See Modifying the Expiring Password Notification email template
Procedure
Start the
ipa-epn.timer
:systemctl start ipa-epn.timer
Once you start the timer, by default, the EPN tool is run every day at 1am.
Additional resources
-
See the
ipa-epn
man page.
35.5. Modifying the Expiring Password Notification email template
This procedure describes how to customize the Expiring Password Notification (EPN) email message template.
Prerequisites
-
The
ipa-client-epn
package is installed.
Procedure
Open the EPN message template:
# vi /etc/ipa/epn/expire_msg.template
Update the template text as required.
Hi {{ fullname }}, Your password will expire on {{ expiration }}. Please change it as soon as possible.
You can use the following variables in the template.
- User ID: uid
- Full name: fullname
- First name: first
- Last name: last
- Password expiration date: expiration
- Save the message template file.
Verification steps
- Run the EPN tool and verify the email notification contains the updated text.
Additional resources
-
See the
ipa-epn
man page.
Chapter 36. Granting sudo access to an IdM user on an IdM client
36.1. Sudo access on an IdM client
System administrators can grant sudo
access to allow non-root users to execute administrative commands that are normally reserved for the root
user. Consequently, when users need to perform an administrative command normally reserved for the root
user, they precede that command with sudo
. After entering their password, the command is executed as if they were the root
user.
If a Red Hat Enterprise Linux (RHEL) 8 host is enrolled as an Identity Management (IdM) client, you can specify sudo
rules defining which IdM users can perform which commands on the host in the following ways:
-
Locally in the
/etc/sudoers
file - Centrally in IdM
This chapter describes creating a central sudo
rule for an IdM client using IdM Web UI. For details on creating local sudo rules on a RHEL 8 host, see Managing sudo access.
Note that you can also define central IdM sudo
rules using the IdM command-line interface.
36.2. Granting sudo access to an IdM user on an IdM client using IdM Web UI
In Identity Management (IdM), you can grant sudo
access for a specific command to an IdM user account on a specific IdM host. First, add a sudo
command and then create a sudo
rule for one or more commands.
Complete this procedure to create the idm_user_reboot sudo rule to grant idm_user the permission to run the /usr/sbin/reboot
command on the idmclient machine.
Prerequisites
- You are logged in as IdM administrator.
- You have created a user account for idm_user in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the command-line interface, see Adding users using the command line.
-
No local idm_user account has been created on idmclient. The idm_user user is not listed in the local
/etc/passwd
file.
Procedure
Add the
/usr/sbin/reboot
command to the IdM database ofsudo
commands:- Navigate to Policy → Sudo → Sudo Commands.
- Click Add in the upper right corner to open the Add sudo command dialog box.
Enter the command you want the user to be able to perform using
sudo
:/usr/sbin/reboot
.Figure 36.1. Adding IdM sudo command
- Click Add.
Use the new
sudo
command entry to create a sudo rule to allow idm_user to reboot the idmclient machine:- Navigate to Policy → Sudo → Sudo rules.
- Click Add in the upper right corner to open the Add sudo rule dialog box.
-
Enter the name of the
sudo
rule: idm_user_reboot. - Click Add and Edit.
Specify the user:
- In the Who section, check the Specified Users and Groups radio button.
- In the User category the rule applies to subsection, click Add to open the Add users into sudo rule "idm_user_reboot" dialog box.
- In the Add users into sudo rule "idm_user_reboot" dialog box in the Available column, check the idm_user checkbox, and move it to the Prospective column.
- Click Add.
Specify the host:
- In the Access this host section, check the Specified Hosts and Groups radio button.
- In the Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "idm_user_reboot" dialog box.
- In the Add hosts into sudo rule "idm_user_reboot" dialog box in the Available column, check the idmclient.idm.example.com checkbox, and move it to the Prospective column.
- Click Add.
Specify the commands:
- In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
- In the Sudo Allow Commands subsection, click Add to open the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box.
-
In the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box in the Available column, check the
/usr/sbin/reboot
checkbox, and move it to the Prospective column. Click Add to return to the idm_sudo_reboot page.
Figure 36.2. Adding IdM sudo rule
- Click Save in the top left corner.
The new rule is enabled by default.
Verification steps
Test that the sudo rule that you have set up on the IdM server works on idmclient by verifying that idm_user can now reboot idmclient using sudo
. Note that propagating the changes from the server to the client can take a few minutes.
- Log in to idmclient as idm_user.
Reboot the machine using
sudo
. Enter the password for idm_user when prompted:$ sudo /usr/sbin/reboot [sudo] password for idm_user:
If sudo is configured correctly, the machine reboots.
36.3. Using an Ansible playbook to ensure sudo access for an IdM user on an IdM client
In Identity Management (IdM), you can ensure sudo
access to a specific command is granted to an IdM user account on a specific IdM host.
Complete this procedure to ensure a sudo
rule named idm_user_reboot exists. The rule grants idm_user the permission to run the /usr/sbin/reboot
command on the idmclient machine.
Prerequisites
- You have installed the ansible-freeipa package on the Ansible controller.
- You know the IdM administrator password.
- You have ensured the presence of a user account for idm_user in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the command-line interface, see Adding users using the command line.
-
No local idm_user account exists on idmclient. The idm_user user is not listed in the
/etc/passwd
file on idmclient.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaservers
in it:[ipaservers] server.idm.example.com
Add one or more
sudo
commands:Create an
ensure-reboot-sudocmd-is-present.yml
Ansible playbook that ensures the presence of the/usr/sbin/reboot
command in the IdM database ofsudo
commands. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml
file:--- - name: Playbook to manage sudo command hosts: ipaserver become: true tasks: # Ensure sudo command is present - ipasudocmd: ipaadmin_password: MySecret123 name: /usr/sbin/reboot state: present
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
Create a
sudo
rule that references the commands:Create an
ensure-sudorule-for-idmuser-on-idmclient-is-present.yml
Ansible playbook that uses thesudo
command entry to ensure the presence of a sudo rule. The sudo rule allows idm_user to reboot the idmclient machine. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml
file:--- - name: Tests hosts: ipaserver become: true tasks: # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient - ipasudorule: ipaadmin_password: MySecret123 name: idm_user_reboot description: A test sudo rule. allow_sudocmd: /usr/sbin/reboot host: idmclient.idm.example.com user: idm_user state: present
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml
Verification steps
Test that the sudo
rule whose presence you have ensured on the IdM server works on idmclient by verifying that idm_user can reboot idmclient using sudo
. Note that it can take a few minutes for the changes made on the server to take effect on the client.
- Log in to idmclient as idm_user.
Reboot the machine using
sudo
. Enter the password for idm_user when prompted:$ sudo /usr/sbin/reboot [sudo] password for idm_user:
If sudo
is configured correctly, the machine reboots.
Additional materials
-
For more details on how to apply
sudo
commands, command groups, and rules in IdM using an Ansible playbook including the descriptions of playbook variables, see the README-sudocmd.md, README-sudocmdgroup.md, and README-sudorule.md Markdown files available in the/usr/share/doc/ansible-freeipa/
directory.
Chapter 37. Ensuring the presence of host-based access control rules in IdM using Ansible playbooks
This chapter describes Identity Management (IdM) host-based access policies and how to define them using Ansible.
Ansible is an automation tool used to configure systems, deploy software, and perform rolling updates. It includes support for Identity Management (IdM).
37.1. Host-based access control rules in IdM
Host-based access control (HBAC) rules define which users or user groups can access which hosts or host groups by using which services or services in a service group. As a system administrator, you can use HBAC rules to achieve the following goals:
- 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.
By default, IdM is configured with a default HBAC rule named allow_all, which means universal access to every host for every user via every relevant service in the entire IdM domain.
You can fine-tune access to different hosts by replacing the default allow_all rule with your own set of HBAC rules. For centralized and simplified access control management, you can apply HBAC rules to user groups, host groups, or service groups instead of individual users, hosts, or services.
37.2. Ensuring the presence of an HBAC rule in IdM using an Ansible playbook
This section describes how to ensure the presence of a host-based access control (HBAC) rule in Identity Management (IdM) using an Ansible playbook.
Prerequisites
- The ansible-freeipa package is installed on the Ansible controller.
- You know the IdM administrator password.
- The users and user groups you want to use for your HBAC rule exist in IdM. See Managing user accounts using Ansible playbooks and Ensuring the presence of IdM groups and group members using Ansible playbooks for details.
- The hosts and host groups to which you want to apply your HBAC rule exist in IdM. See Managing hosts using Ansible playbooks and Managing host groups using Ansible playbooks for details.
Procedure
Create an inventory file, for example
inventory.file
, and defineipaserver
in it:[ipaserver] server.idm.example.com
Create your Ansible playbook file that defines the HBAC policy whose presence you want to ensure. To simplify this step, you can copy and modify the example in the
/usr/share/doc/ansible-freeipa/playbooks/hbacrule/ensure-hbacrule-allhosts-present.yml
file:--- - name: Playbook to handle hbacrules hosts: ipaserver become: true tasks: # Ensure idm_user can access client.idm.example.com via the sshd service - ipahbacrule: ipaadmin_password: MySecret123 name: login user: idm_user host: client.idm.example.com hbacsvc: - sshd state: present
Run the playbook:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-new-hbacrule-present.yml
Verification steps
- Log in to the IdM Web UI as administrator.
- Navigate to Policy → Host-Based-Access-Control → HBAC Test.
- In the Who tab, select idm_user.
- In the Accessing tab, select client.idm.example.com.
- In the Via service tab, select sshd.
- In the Rules tab, select login.
- In the Run test tab, click the Run test button. If you see ACCESS GRANTED, the HBAC rule is implemented successfully.
Additional resources
-
For more details about and examples of, configuring HBAC services, service groups, and rules using Ansible, see the README-hbacsvc.md, README-hbacsvcgroup.md, and README-hbacrule.md Markdown files. These files are available in the
/usr/share/doc/ansible-freeipa
directory. Also see the playbooks available in the relevant subdirectories of the/usr/share/doc/ansible-freeipa/playbooks
directory.
Chapter 38. Public key certificates in Identity Management
This chapter describes X.509 public key certificates, which are used to authenticate users, hosts and services in Identity Management (IdM). In addition to authentication, X.509 certificates also enable digital signing and encryption to provide privacy, integrity and non-repudiation.
A certificate contains the following information:
- The subject that the certificate authenticates.
- The issuer, that is the CA that has signed the certificate.
- The start and end date of the validity of the certificate.
- The valid uses of the certificate.
- The public key of the subject.
A message encrypted by the public key can only be decrypted by a corresponding private key. While a certificate and the public key it includes can be made publicly available, the user, host or service must keep their private key secret.
38.1. Certificate authorities in IdM
Certificate authorities operate in a hierarchy of trust. In an IdM environment with an internal Certificate Authority (CA), all the IdM hosts, users and services trust certificates that have been signed by the CA. Apart from this root CA, IdM supports sub-CAs to which the root CA has granted the ability to sign certificates in their turn. Frequently, the certificates that such sub-CAs are able to sign are certificates of a specific kind, for example VPN certificates. Finally, IdM supports using external CAs. The table below presents the specifics of using the individual types of CA in IdM.
Table 38.1. Comparison of using integrated and external CAs in IdM
Name of CA | Description | Use | Useful links |
---|---|---|---|
The | An integrated CA based on the Dogtag upstream project | Integrated CAs can create, revoke, and issue certificates for users, hosts, and services. | Using the ipa CA to request a new user certificate and exporting it to the client |
IdM sub-CAs |
An integrated CA that is subordinate to the |
IdM sub-CAs are CAs to which the | Restricting an application to trust only a subset of certificates |
External CAs | An external CA is a CA other than the integrated IdM CA or its sub-CAs. | Using IdM tools, you add certificates issued by these CAs to users, services, or hosts as well as remove them. |