The FreeIPA Master Class - Part 5

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:

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

1. Create a host group

ipa hostgroup-add webservers

2. Add hosts to the group

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

3. Verify membership

ipa hostgroup-show webservers

Creating User Groups¶

Access rules should typically reference groups rather than individual users.

Example groups:

• developers
• sysadmins
• auditors

1. Create a group

ipa group-add developers

2. Add users

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

Creating an HBAC Rule¶

Now we can combine these components into an access rule.

1. Create the rule

ipa hbacrule-add allow_developers_ssh

2. Allow SSH as the service

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

3. Allow the user group

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

4. Allow the host group

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

5. 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.

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¶

1. Create a sudo rule

ipa sudorule-add sysadmin-sudo

2. Add user group

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

3. Allow rule on all hosts

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

4. 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.

1. Create a command object

ipa sudocmd-add /usr/bin/systemctl

2. 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:

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.

Next: The FreeIPA Master Class - Part 6