Published Feb. 3, 2025, 3:23 a.m. by dwest
In Part 1 of this series, we introduced directory services and installed a FreeIPA server. In Part 2, we joined systems to the domain and verified that centralized authentication was working. Now that the infrastructure is running and machines are enrolled, it’s time to start managing identities.
Identity management is the core function of any directory server. In FreeIPA, this means managing:
In this article, we’ll focus on the most common administrative tasks: creating users, managing groups, and controlling login access.
FreeIPA stores identity information in its LDAP directory. The LDAP (Light Weight Directory Access Protocol) is just a type of database designed for storing and retrieving identity and authentication objects to provide access to a system. Several object types make up the identity structure of the environment.
The most important ones include:
| Object Type | Description |
|---|---|
| Users | Individual login accounts |
| Groups | Collections of users |
| Hosts | Systems joined to the domain |
| Host Groups | Collections of systems |
| Services | Kerberos-enabled services such as HTTP or CIFS |
These objects are combined with access rules to control how users interact with systems. It answers the questions of:
Users can be created either through the WebUI or through the CLI. The CLI is often preferred in automated environments.
Basic user creation looks like this:
ipa user-add jsmith --first=John --last=Smith --email=jsmith@example.com
After creating the account, set a password:
ipa passwd jsmith
The user will be required to change the password at first login.
You can find most user information just from the CLI. Below is a list of some of the most useful commands for displaying user information:
List Users
ipa user-find
Display Details for a Specific User
ipa user-show jsmith
Example output:
User login: jsmith
First name: John
Last name: Smith
Home directory: /home/jsmith
Login shell: /bin/bash
Just like viewing user information, you can also make changes to them from the CLI as well.
Update User Info (Example: Title)
ipa user-mod jsmith --title="Systems Engineer"
Lock the Users Account
ipa user-disable jsmith
Unlock a Users Account
ipa user-enable jsmith
It is generally good practice to never delete a user account. This is because the users UID, GID and possibly access permissions could get reused by the next account that is created. It makes the “auditing” part of FreeIPA management a bit messy since the audit trail blurs the line between two different users. However, there are certain occasions where deleting an account might be necessary, such as an account creation error or building special integrations with other identity providers. In these situations, you can delete the accounts with the following:
ipa user-del jsmith
| Note: |
|---|
| This removes the user from the directory but does not delete files on systems where the user previously logged in. That needs to be taken care of as part of a separate process |
Groups allow administrators to manage permissions at scale. Instead of assigning permissions to individual users, you assign them to groups.
Example Groups:
adminsdeveloperswebteamCreate a New Group
ipa group-add developers
Add a User to a Group
ipa group-add-member developers --users=jsmith
You can also add multiple users:
ipa group-add-member developers --users=jsmith,bjones
View Group Membership
ipa group-show developers
Example output:
Group name: developers
Member users: jsmith bjones
Remove a User from a Group
ipa group-remove-member developers --users=jsmith
Just as users can be grouped, so can hosts. This is useful when applying access policies to large numbers of machines.
Example host group:
webservers
Create a Host Group
ipa hostgroup-add webservers
Add Hosts to the Group
ipa hostgroup-add-member webservers --hosts=web01.example.com
One of FreeIPA’s most powerful features is Host-Based Access Control.
HBAC rules determine:
This allows administrators to enforce security policies across an entire infrastructure.
Example Access Policy
| Component | Value |
|---|---|
| Users | developers |
| Hosts | webservers |
| Service | ssh |
This rule allows members of the developers group to SSH into systems in the webservers host group.
ipa hbacrule-add allow_developers_ssh
ipa hbacrule-add-service allow_developers_ssh --hbacsvcs=sshd
ipa hbacrule-add-user allow_developers_ssh --groups=developers
ipa hbacrule-add-host allow_developers_ssh --hostgroups=webservers
ipa hbacrule-enable allow_developers_ssh
After creating HBAC rules, test authentication:
ssh jsmith@web01.example.com
If access is denied, check:
ipa hbacrule-find
You can also use:
sssctl user-checks jsmith
This tool shows how SSSD evaluates access policies.
FreeIPA allows administrators to enforce password policies globally or per-group.
View the current policy
ipa pwpolicy-show
Example output:
Max lifetime: 3650 days
Min lifetime: 1 hour
Min length: 8
Max failures: 6
Modify the Global Password Policy
ipa pwpolicy-mod global_policy
--minlength=12
--maxfail=5
This enforces stronger password security across the environment.
A few guidelines that make FreeIPA deployments easier to manage:
Use Groups for Access. Avoid granting permissions directly to users.
Use Host Groups for Infrastructure. Instead of managing access host-by-host:
Avoid Manual Changes on Clients. Once systems are enrolled, authentication should be managed centrally through FreeIPA. Manual modifications to /etc/passwd or /etc/group can cause conflicts.
So far in this series we have covered:
In the next part of the FreeIPA Master Class, we will explore one of the most important technologies behind FreeIPA:
Kerberos Authentication
We’ll cover:
Understanding Kerberos is key to mastering FreeIPA.
Next: The FreeIPA Master Class - Part 4
The FreeIPA Master Class - Part 4
The FreeIPA Master Class - Part 2
The FreeIPA Master Class - Part 1
There are no comments.