How to manage users and groups in FreeIPA Server

FreeIPA (Identity Management) centralizes LDAP directory data, Kerberos authentication, DNS, and related policies. After you install a server and obtain an administrative Kerberos ticket (kinit), day‑to‑day work is mostly users, groups, and optional HBAC / sudo rules (those are separate topics; this article focuses on accounts and group membership).

You will learn how to

Authenticate with kinit and run ipa commands.
Create POSIX, non-POSIX, and external groups; assign optional fixed GIDs.
Find, show, and delete groups; add members and nested groups.
Create and lock users, set passwords, and inspect raw LDAP-style attributes.
Use member managers (delegated “who can edit membership”).
Migrate local /etc/passwd accounts with a safer batch pattern (with caveats).

Prerequisites

A working FreeIPA server and DNS/realm configuration.
A client or server where the ipa CLI is installed (typically an enrolled IPA client or the server itself).
A Kerberos principal allowed to run the commands below (usually admin or another account with sufficient privileges).

Server setup

Clients

Kerberos ticket

To proceed, obtain a ticket for an administrative principal (example realm IPA.CITIZIX.COM—replace with yours):

1
2
kinit admin
klist

Default ticket lifetime is commonly 24 hours (policy-dependent). If ipa replies with “Insufficient access” or session errors, refresh with kinit again.

Group concepts in FreeIPA

A group gathers principals so you can attach password policies, sudo, HBAC, RBAC roles, and other policy to many accounts at once. Members can be:

FreeIPA users
Other FreeIPA groups (nesting)
External identities (via external groups and trust/AD integration—not fully covered here)

Group types

Type	POSIX (GID)	Typical use
POSIX (default)	Yes	Linux login, file ownership, `groups` on clients
Non-POSIX	No	Policy-only bundles, some trust scenarios
External	No	Maps to AD or another source via external member commands

POSIX groups carry gidNumber for the Linux NSS stack. Design ID ranges (especially with trusts) so numeric UIDs/GIDs never collide.

Built-in groups (common)

admins — administrative IPA users (includes admin by default)
ipausers — default shell group for IPA users (membership semantics can vary by version; always check with ipa group-show)
trust admins — manages Active Directory trust configuration (name contains a space; quote it in shells: "trust admins")

When a user joins a group, policies tied to that group apply—membership alone does not grant shell sudo until you configure sudo rules and HBAC.

Create groups

POSIX group (default)

1
ipa group-add --desc='QA Engineers' qa

Non-POSIX group

1
ipa group-add analysts --nonposix --desc='Reporting (non-POSIX)'

External group

Used as part of trust workflows; exact nesting into POSIX groups follows IPA docs for your version:

1
ipa group-add ad_users_external --external --desc='External membership container'

Custom GID

Pick a GID inside an allocated range and avoid clashes with local groups on clients:

1
ipa group-add ops --desc='Operations' --gid=100500

Your IPA build may expose the flag as --gid or --gidnumber. Run ipa help group-add on your server and use the option it documents to avoid ID conflicts in your ID range.

Example output (abbreviated):

1
2
3
4
5
6
----------------
Added group "qa"
----------------
  Group name: qa
  Description: QA Engineers
  GID: 1063800004

Find and inspect groups

1
2
3
4
5
6
7
8
ipa group-find                    # all (subject to ACLs)
ipa group-find --posix            # POSIX only
ipa group-find --nonposix         # non-POSIX only
ipa group-find --external         # external only
ipa group-find dev                # substring search
ipa group-find --user=jdoe        # groups containing user jdoe
ipa group-find --no-user=jdoe     # groups that do not contain jdoe
ipa group-show qa                 # one group; use real name

Note: Filtered ipa group-find output depends on your IPA version and ACLS; treat tutorial counts as illustrations.

Group membership (members—not managers)

Add a user to a group:

1
ipa group-add-member qa --users=jdoe

Nest a group inside another:

1
ipa group-add-member engineering --groups=development

Remove a group (only when policy allows):

1
ipa group-del qa

Member managers (delegation)

Member managers can add/remove members of a target group without being full IPA admins.

Add jdoe as a member manager of developers:

1
ipa group-add-member-manager developers --users=jdoe

Allow qa (a group principal) to co-manage developers:

1
2
ipa group-add-member-manager developers --groups=qa
ipa group-show developers

Remove managers:

1
2
ipa group-remove-member-manager developers --users=jdoe
ipa group-remove-member-manager developers --groups=qa

Nesting groups

To add group_b as a member of group_a:

1
ipa group-add-member group_a --groups=group_b

Remove members from a group

Confirm membership first:

1
ipa group-show qa

Remove users or nested groups:

1
2
ipa group-remove-member qa --users=jdoe
ipa group-remove-member group_name --users=user1 --users=user2 --groups=nested_group

Managing users

Interactive create

1
ipa user-add

Follow prompts for first name, last name, login, and so on.

Non-interactive create (common options)

FreeIPA uses long options with double dashes:

Option	Meaning
`--first`	Given name
`--last`	Surname
`--cn`	Full name override
`--homedir`	Home directory
`--shell`	Login shell
`--email`	Mail
`--password`	Prompt for initial password
`--random`	Generate a random password (prints once)
`--mobile`	Mobile number

Example:

1
2
3
4
5
ipa user-add jdoe \
  --first=John \
  --last=Doe \
  --email=[email protected] \
  --shell=/bin/bash

Password set and change

You do not need to delete and recreate a user to set a password. After ipa user-add, use:

1
ipa passwd jdoe

Or modify interactively:

1
ipa user-mod jdoe --password

With --password on user-add, IPA prompts during creation:

1
ipa user-add jdoe --first=John --last=Doe --password

Lock and unlock

1
2
ipa user-disable jdoe
ipa user-enable jdoe

Search and show

1
2
3
ipa user-find jdoe
ipa user-show jdoe
ipa user-show --raw jdoe          # LDAP-style attribute names

Modify attributes

General form:

1
ipa user-mod LOGIN [options]

Example (shell):

1
ipa user-mod jdoe --shell=/bin/zsh

Delete user

1
ipa user-del jdoe

(List multiple logins to remove several accounts in one call.)

Bulk import from local `/etc/passwd` (example)

Warning: test on a lab IDM first. UID/GID collisions, weak passwords, and wrong GECOS parsing can cause painful clean-up.

Prefer SSSD + migration mode or a proper IDM migration plan for production.
The following only illustrates iterating local users in a four-digit UID range (adjust awk bounds to match your policy).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
#!/usr/bin/env bash
set -euo pipefail

while IFS=: read -r login _ uid _ _ gecos _; do
  [[ "$uid" =~ ^[0-9]+$ ]] || continue
  (( uid >= 1000 && uid < 10000 )) || continue

  first="${gecos%%,*}"
  first="${first%% *}"
  last="${gecos#* }"
  [[ -n "$first" ]] || first="$login"
  [[ -n "$last" ]] || last="$login"

  if ipa user-show "$login" &>/dev/null; then
    echo "skip existing: $login"
    continue
  fi

  ipa user-add "$login" --first="$first" --last="$last" --random
done < /etc/passwd

Use ipa passwd or force change on first login via password policy after import. Never pipe meaningless data into ipa user-add; authentication must be deliberate.

Operational tips

Principle of least privilege: grant admin only where needed; use roles and member managers for help-desk tasks.
ID ranges: document POSIX UID/GID ranges for IPA, trusts, and manual assigns (--gidnumber).
Quotes: group names with spaces need shell quoting ("trust admins").
Next steps: tie groups to HBAC rules (who may log in where) and sudo rules (what they may run).

Conclusion

With kinit and the ipa CLI you can create POSIX and policy groups, delegate membership with member managers, nest groups, and lifecycle user accounts (password, lock, delete). Pair this workflow with clients enrolled via ipa-client-install, SSSD, and central password policy so Linux hosts honor the same identities you manage in FreeIPA.

If you want a follow-up article on HBAC, sudo, or host enrollment patterns on Rocky/Alma 9, say which scenario you care about first.