Building An Enterprise - EP 03 - FreeIPA Server Configuration

This is article two on a series of designing an enterprise ecosystem on SUSE/openSUSE, which is its self part one of a series on designing and building a Linux Enterprise. This article will refer to the FreeIPA tool which is the FOSS upstream project for Red Hat Identity Management Server.

If you need help setting installing FreeIPA please refer to this article.

Managing FreeIPA can be a pain, much like every other directory server, so instead of boring you with intricate details, please skip to the section that covers the rudimentary knowledge you need or wish to understand. Note this an introductory article to cover what things are and where they are, more detailed information will follow as we start EP 4 with accompanying lab entries on building the infrastructure.

Pleas note this article is dry, and experienced users will find it even dryer. But if you are new to this software please read through so you understand the fundamentals.

Users

Users are broken down into three categories:

1. Active Users (Users who's permissions are currently active, and can perform actions)
2. Stage Users (Users who will become active in the future, but cannot yet perform actions)
3. Preserved Users (Users who were once active, but are now being "preserved" for any reason like compliance)

Below these categories are then "Enabled" and "Disabled" Active Users. A user who is Enabled is active and can login, and a user who is disabled cannot login. Use the disabled for things such as vacations, or medical leave.

User Settings:

User Settings break down into the following:

1. Identity Settings
   Information about the user that establishes who they are
2. User Groups
   Controls the groups they are assigned to
3. Netgroups
   For NIS clients, disregard unless using a legacy deployment
4. Roles
   Privilege Roles such as "User Administrator" or "IT Specialist"
5. HBAC Rules
   Controlling what they can login to
6. Sudo Rules
   Controlling what commands they can run as sudo
7. Subordinate ID's
   Control subuid and subgid for things like container hosts

We will cover all other items in more detail as we get to their administration sections, but for now here are the important items unique to the User Information Page.

1. Login Shell
   Use this to set a restricted or just different user shell to utilize on login, this is a great feature to keep in mind for shared users that may be responsible for actions such as container manager
2. Home Directory
   Set the directory to be created for the user on login. Keep this in mind for organizational management. The default it to use just the user's first name, which is often a bad idea as your organization grows.
3. User Authentication Types
   By default this is not selected which allows all types of authentication. Select a specific type to restrict login to that particular type of login.
4. Radius Configuraitons
   Use this group of setting to set radius configuration such as username for your enterprise wifi setup.
5. Email Address
   VERY IMPORTANT! Most FreeIPA servers will not be at the tld of the enterprise, so ensure you update new users with their tld email such as user@domain.local instead of user@net.domain.local. Otherwise the users will need to use their sub domain to login.
6. SMB Attributes
   Set these to setup SMB Home directories and auto mounts. This is not used a lot in modern times, but is still an important legacy feature for many organizations

Hosts

Hosts are just that, host machines that are joined to a domain. They work a lot like users because in LDAP they are able to be bound to many of the same things as users. For example a host can have Sudo and HBAC rules the same way that a user can, allowing for you to setup Sudo or HBAC from either direction depending on your organization design needs. That being said hosts have a few additional things unique to hosts:

1. Certificates
   FreeIPA has a certificate authority built into it. This allows it to sign and issue certificates. These certificates are specific to either a host, or as we cover later a service. You can add/acquire these certificates by clicking "Actions" + "New Certificate". After creation certificates can be deleted, revoked, and managed in the FreeIPA UI as a "Host Certificate".
2. Enrollment/One Time Password/Keytab
   Hosts have a Kerberos keytab, this keytab allows the host to authenticate with Kerberos to the server. This keytab file is pulled to the server with the FreeIPA API when the host is "Joined" to the domain. To pull this keytab you will need a password, which is where the One Time Password comes is set, so that a user password does not need to be entered to join a new host to the domain.
3. SSH Public Keys
   SSH Public Keys can be managed by FreeIPA by adding and/or deleting them from the Web GUI, this will allow you to incorporate enterprise key management into the domain without too much hassle.
4. Keytab Restrictions
   Keytab creation and retrieval can be a serious security risk, use this section to set allowed users, hosts, and groups that can retrieve and/or create this hosts keytab file.

Services

Services cover everything from DNS to HTTP to LDAP. These services are can be managed independently, but can also be "assigned" to hosts with tight access control rules, certificates, and even their own keytab's for SSO. Services will have the same general options as hosts, including certificates and keytabs but also a few important features such as:

1. PAC Type
   The PAC is a part of the Kuberos service's authentication ticket and is typically used to retrieve information about the authenticated user and their assigned access right or group memberships. This can be set to "Inherited from server configuration" or "Override inherited settings". Only use the "Override inherited settings" if you are using FreeIPA in a legacy installation or trying to achieve a specific type of integration with a service that might only support MS-PAC or PAD.
2. Trusted for delegation
   This is a flag for Kerberos tickets to allow a ticket to be forwarded or delegated to a specific server. This can be important when setting up interoperability with Microsoft Active Directory Servers which may need to communicate with FreeIPA's TGT.

Groups

Groups are broken down into

1. User Groups
   Used to setup user group management for user based group policy settings
2. Host Groups
   Used to setup Host group management for host based group policy settings
3. Netgroups
   For managing NIS clients, disregard unless using a legacy deployment

We will cover group management broadly as the specifics depend on features covered later such as Sudo and HBAC rules. But in a broad sense you create a group, assign users or hosts to that group, and then assign HBAC or Sudo rules to that group to allow user and/or host based access to specific privileges.

ID Views

ID Views are used to override specific user item such as their home directory or user login on a specific host. Its usage is uncommon, but an important tool to remember as your organization grows or you have multiple mutual trusts which may require special limited configurations.

Auto Member User/Host

The title says it all, use this page to setup inclusive and exclusive rule parameters to make users or hosts automatically members of a specific group. This is vital for auto setting up things like servers to always be in a server group, or even to group servers by their operating system. It may seem boring but if you plan to have a large organization, you will need to spend a lot of time thinking about this page.

Subordinate IDs

We covered this in the Users Pages, but this tab will allow you to visualize all of the Subordinate IDs that are assigned inside of the domain.

Host-Based Access Control

HBAC Rules allow yous to setup specific group policies on specific machines to access specific features. Technically the next section Sudo is also part of this, but it is logically separated in the UI to make the management easier. HBAC is broken into the following parts:

1. Rules
   When/Where Can you do it
2. Services
   What can you do
3. Service Groups
   How are you organized

HBAC Rules

The simplest item what When/Where can you do something, the default here is the "allow_all" rule which allows any user to access any host from any other host. This is an important starting point so that all users can login, but once you grow you'll want to restrict this. Lets make a logical separation rule using simple access controls for login:

1. Add a new rule called "user_login"
2. Open the rule and under "Who" select "Specified Users and Groups"
3. Add the user group "ipausers"
4. Under "Accessing" select "Specified Hosts and Groups"
5. Now select "Add" and add a Host Group, my favorite is "workstation_aaa" (the default name I use for workstations in a small office setting)
6. Now under "Via Service" select "Specified Services and Groups"
7. Select Add HBAC Services and add "login" "gdm" "gdm-password" so that the user can now login to the computer on Gnome Display Manager and be able to update their password.

HBAC Services

Services are sorted by their service names. I wish it was more fancy to write about, but services are what they say they are. For example, the Gnome Display Manager service is just "add service" and enter "gdm", all other services work the same way. This is very boring so don't over complicate it.

HBAC Service Groups

Again don't over complicate it this is a group id for services that are used together. For example sudo requires "sudo" and "sudo-i" to run, so you can group both items together in to the group "sudo". Just keep it simple and don't confuse yourself with any complex naming.

Sudo

Sudo rules allow you to define what a user can run as sudo, who they can impersonate with sudo, and where they can run it.

Sudo Commands

The fundamental rule of Sudo Commands in FreeIPA is give the full command path. It is never the command "mv" it is "/bin/mv". If you fail to give the full command path the command will always fail to get permission from FreeIPA's sudo setup. To create a command navigate to the "Sudo Commands" page and hit "Add" then enter the full command path and give it a description.

Sudo Command Groups

Commands can be very restrictive, for example I have a group of users that I want to only be able to use sudo to raise and lower a company tailscale vpn, so I give them only permission to user "sudo tailscale up" and "sudo tailscale down". Since it is only two commands I can manage them independently, but when we get to hundreds of command I will need to setup group management, This is where I can create something like the "Sudo Command Groups" and put both commands in the "tailscale_end_users" group.

To create a group, go to the "Sudo Command Groups" page and select "Add", give the grup a name, and then navigate into the group. From there add the commands you want to manage together into the group.

Sudo Rules

Welcome to the hard part. Fortunately you are allready used to how this looks now so you an just create a sudo rule by hitting the add button, giving it a name, and then navigating in to find the same logical layout as I've described before with HBAC and other settings.

1. Sudo Order
   This is an integer, Sudo rules are processed top to bottom in the sudoers file on a machine and it works the same in FreeIPA sudo rules, they go top to bottom and can conflict if not in the right order. Keep in mind to choose big numbers when setting these rules up as rules cannot share a number, and the number must be an integer.
2. Sudo Options
   This sets things like if a password is required to authenticate the sudo action.
3. Who
   Use this to specify what uses and user groups can use this rule
4. Access this host
   Use this to set what host this applies to
5. Run Commands
   Set what commands or command groups this rule applies too
6. As Whom
   Sets the RUnAs Users and groups for impersonation

SELinux User Mapping

SELinux User mapping is important when FreeIPA users need to do defined tasks on a server such as run a web server. This mapping reduces SELinux conflicts but can be a bit tricky (says anyone using SELinux in production). The intracacies are pretty detailed, but fundamentally you just need to create a policy with a name and an SELinux user such as "user_u:s0" and then you can assign users, hosts, and HBAC rules to this SELinux configuration to allow users and hosts to have specific SELinux bindings for specific tasks and privileges

Password Policies

Use this to set a more or less restrictive password policy for you systems, I won't go into detail on this as password policies are more often set by regulatory compliance standards than preference.

Kerberos Ticket Policy

The security minded among you will need this page to set the Kerberos ticket policy down from the default of 7 Days of Max Renew and a max life of 1 day down to something more safe for your organization. Don't touch anything here unless you are well past the need of using this guide as anything more than a "Where is that thing again".

Passkey Configuration

This is a sad checkbox page for "Require user verification" You should leave this always on, and I'm not sure why it has a whole page to begin with.

Certificates

We've covered how to manage certificates on a host and service based level. Please manage them from there, and leave this page to detailed professionals.

OTP Tokens

You can use this page to add One Time Password Token generation into the server. It can be either Time based or Counter Based up to you, but definitely stay away from this page unless you are well past this guide. Instead refer to Identify Provider References

For those still curious, this can be used to setup OTP Token based MFA directly in FreeIPA. I highly recommend this for server authentication, but it is a bit too much to handle directly for your typical end user. If you really want to get into this refer to the FreeIPA docs directly and at your own risk as this can lock you out of your own servers.

Radius Server

Use this to join and/or allow your users to authenticate against Radius for WPA2/3 - Enterprise. I won't go into this as Radius is typically bound to other systems all external of FreeIPA.

Identity Provider References

Are you joining a bunch of things that shouldn't touch? Would you like a strong second layer of OAuth 2.0 in your ecosystem? Then Identity Provider References are the place to go for you. This page lets you enroll external OAuth 2.0 into your credential options for either single authentication or MFA authentication. Please note this is still an upstream authentication so it can't replace domain trusts, but it can be an excellent choice for safe single password management without having to mix up a myriad of complex domain servers.

To set it up, get your OAuth Details and enter them into the UI, then select that login method for your user in the user or user groups page.

Automounts

Automounts should typically not be used in a modern infrastructure solution, in favor of more distributed file system solution. But if you are using this you can use this page to setup keys and mount points to ensure that directories are automatically mounted for file sharing at login.

DNS

DNS is broken into Zones, Forward Zones, Servers, and Global Configuration. I will only cover basic configuration changes as the rest should be done automatically when a new host or service is added.

1. Update DNS Servers
   1. Go to "DNS Servers"
   2. Select the IPA Server
   3. Change a forwarder address
   4. Select Save
2. Add a forward zone (i.e. forward requests from secret.domain.top to a specific server)
   1. Go to "DNS Forward Zones"
   2. Add a zone
   3. Enter the name of the domain
   4. Add the forwarder dns server
3. Add a service IP Address (such as when adding a horizontal scaling node)
   1. Go to "DNS Zones"
   2. Select the domain (i.e. net.domain.local)
   3. Select "Add"
   4. Enter the name of the service (i.e. nextcloud)
   5. Record Type of A
   6. Ip address of the server

DNS substantial, but this should get you navigating around and getting a feel for what to alter where.

IPA SERVER

This tab covers configurations for the server its self and covers:

1. Role-Based Access Control
2. ID Ranchers
3. Realm Domains
4. Trusts
5. Topology
6. API Browser
7. Configuration

Role-Based Access Control

This is where you add specific user permission roles such as enrolling hosts into the domain. I won't go into specific details as the defaults are sufficient to cover most deployments, but as you grow come back to here to get very fine grained administration controls over what types of users can do what to your servers.

ID Ranges

ID's cannot conflict, I repeat myself ID's cannot conflict! This page is VITAL TO ALTER if you are using FreeIPA in a trust with another domain. Ensure that the domain POSIX ID's do not conflict between your domains so that users do not end up creating ID errors or worse, gaining permissions they shouldn't. The ranges are easy to adjust, and a linear integer, so alter this if necessary and ignore if not necessary.

Realm Domains

This is where you add additional domains that the server can run. For example if you are using net.domain.local, and you want services to run on nextcloud.domain.local you will have to add the domain domain.local for your Certificate Authority to sign the Certificates for that domain.

Trusts

Trusts are telling your FreeIPA server to trust users of another domain. Do not do this lightly, and do not undertake it from a guide, but I will give you some pointers on where to start.

There are two types of trusts, Two-way and external. Two-way is when you both trust each other, and external is when you are trusting the other domain. This is fairly straight forward to setup and can be done in the GUI, but be aware that things like the ID Range mapping and DNS Forward zones have to be setup first to ensure everything works.

Topology

Use this page to view your servers, roles, and other attributes of the Directory Server. This page is informative but is primarily a visualization tool to understand locations and relationships.

API Browser

This is a cheat sheet for the FreeIPA API. Feel free to disregard until you are building an API integration.

Configuration

This page contains the defaults for the server, this should remain untouched unless you have a specific preference you are attempting to change.

I hope this didn't all bore you too much, it is a relatively dry subject. But I do promise that the general listings are useful when going through the UI as some things while very obviously labeled, are scary to new users. Hopefully this takes the edge off that fear of a very dry subject.