The FreeIPA Master Class - Part 5

Published Feb. 17, 2025, 5:18 a.m. by dwest

Host-Based Access Control (HBAC) and Sudo Policies

In the previous parts of this series we covered:

Installing and configuring FreeIPA
Joining systems to the domain
Managing users and groups
Understanding Kerberos authentication

At this point, users can authenticate across the infrastructure. But authentication alone does not determine what users are allowed to do.

This is where access control policies come into play.

FreeIPA provides two major mechanisms for controlling user access:

HBAC (Host-Based Access Control) - controls which users can log into which systems
Sudo Policies - controls which users can run privileged commands

Together, these systems allow administrators to centrally manage login and privilege access across an entire environment.

Understanding Host-Based Access Control (HBAC)

HBAC rules define who can log in, where they can log in, and how they can log in.

An HBAC rule consists of three main components:

Component	Description
Users	Individual users or user groups
Hosts	Specific hosts or host groups
Services	Login services (SSH, login, sudo, etc.)

Example rule:

Users: developers
Hosts: webservers
Services: ssh

This means:

“Members of the developers group can SSH into hosts in the webservers group.”

HBAC rules are evaluated during the authentication process through SSSD on the client machine.

Default HBAC Behavior

When FreeIPA is first installed, a default rule exists:

allow_all

This rule allows all users to log into all hosts.

While convenient for testing, this rule should typically be disabled in production environments.

To view current HBAC rules:

ipa hbacrule-find

Creating Host Groups

Host groups simplify policy management by grouping systems together.

Example host groups:

webservers
databases
devsystems
adminhosts

Create a host group

ipa hostgroup-add webservers

Add hosts to the group

ipa hostgroup-add-member webservers --hosts=web01.example.com

Verify membership

ipa hostgroup-show webservers

Creating User Groups

Access rules should typically reference groups rather than individual users.

Example groups:

developers
sysadmins
auditors

Create a group

ipa group-add developers

Add users

ipa group-add-member developers --users=jsmith

Creating an HBAC Rule

Now we can combine these components into an access rule.

Create the rule

ipa hbacrule-add allow_developers_ssh

Allow SSH as the service

ipa hbacrule-add-service allow_developers_ssh --hbacsvcs=sshd

Allow the user group

ipa hbacrule-add-user allow_developers_ssh --groups=developers

Allow the host group

ipa hbacrule-add-host allow_developers_ssh --hostgroups=webservers

Enable the rule

ipa hbacrule-enable allow_developers_ssh

Now only developers can SSH into the webservers group.

Testing HBAC Rules

Testing access is simple. From a client system, attempt to login to it using SSH

ssh jsmith@web01.example.com

If access fails unexpectedly, use the SSSD diagnostic tool to determine why

sssctl user-checks jsmith

This shows how access policies are evaluated.

Disabling the Default Allow Rule

Once custom rules are in place, disable the default rule

ipa hbacrule-disable allow_all

After this point, only defined HBAC rules will permit access.

Note:
Be careful. Misconfigured rules can lock administrators out of systems.

Understanding Sudo Policies

While HBAC controls who can log into systems, it does not control what users can do after login.

That’s where Sudo policies come in.

Sudo rules define:

Which users can run privileged commands
Which commands they can run
On which hosts
As which users

Example:

Users: sysadmins
Hosts: all servers
Commands: /usr/bin/systemctl
RunAs: root

This allows system administrators to manage services without granting full root access.

Creating a Sudo Rule

Create a sudo rule

ipa sudorule-add sysadmin-sudo

Add user group

ipa sudorule-add-user sysadmin-sudo --groups=sysadmins

Allow rule on all hosts

ipa sudorule-add-host sysadmin-sudo --hostgroups=allhosts

Allow commands

ipa sudorule-add-allow-command sysadmin-sudo --sudocmds=ALL

This grants full sudo privileges.

Creating Restricted Sudo Commands

For tighter security, define specific commands.

Create a command object

ipa sudocmd-add /usr/bin/systemctl

Then add it to the rule

ipa sudorule-add-allow-command sysadmin-sudo --sudocmds=/usr/bin/systemctl

Now administrators can only manage services.

Testing Sudo Policies

After logging in as a user, list their existing privileges

sudo -l

Example output:

User jsmith may run the following commands:
(root) /usr/bin/systemctl

If sudo access fails, verify:

ipa sudorule-find

Also confirm the client updated its policies:

sss_cache -E

Best Practices for Access Control

A few guidelines make FreeIPA access control much easier to maintain.

Always Use Groups. Avoid referencing individual users in policies. This makes onboarding and offboarding users much simpler.
- Users -> Groups -> Access Policies
Use Host Groups for Infrastructure. This allows policies to apply to entire infrastructure tiers.
- Example structure:
```
webservers
dbservers
adminhosts
```
Start With Deny-By-Default. Disable the default allow rule and explicitly define access policies. This follows the principle of least privilege.

Example Enterprise Access Model

A typical policy structure might look like this:

Group	Access
developers	SSH access to development systems
sysadmins	SSH + sudo access to all servers
auditors	Read-only access to selected hosts

This approach allows centralized control across hundreds or thousands of systems.

What’s Next?

So far in the FreeIPA Master Class we have covered:

Directory server fundamentals
Installing FreeIPA
Domain enrollment
Identity management
Kerberos authentication
Access control policies

In the next part of the series we will explore:

FreeIPA Replication and High Availability

We will cover:

Replica architecture
Multi-master replication
Certificate authority replication
Designing highly available FreeIPA environments
Troubleshooting replication issues

Understanding replication is essential for building reliable identity infrastructure.