How FreeIPA ID ranges for AD users decide Linux UIDs and GIDs
The ID range you choose for AD users determines the numeric UIDs and GIDs their Linux sessions receive, and that mapping is hard to reverse once users log in. When Linux hosts enrolled in FreeIPA must serve AD users through a cross-forest trust, FreeIPA needs an ID range for those users. FreeIPA can establish a cross-forest trust with Active Directory through Samba components, and the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. The trust creates the relationship, but the ID range decides how each AD security identifier becomes a POSIX identity on your hosts.
An ipa-ad-trust range computes UIDs and GIDs from the AD SID of each user or group, so the numbers come from FreeIPA's allocation rather than from anything stored in AD. An ipa-ad-trust-posix range instead reads the POSIX attributes that AD administrators have already set on the accounts, such as uidNumber and gidNumber, so the numbers come from AD. Confirm the exact range types and their behavior against the FreeIPA Trusts documentation and your installed release before you commit, because the two types handle missing or conflicting POSIX attributes differently.
Teams need this decision at trust setup, before the first AD user logs in. If AD already has trusted, maintained UID and GID values that other Unix systems use, the POSIX-attribute approach keeps numbers consistent across estates. If AD has no POSIX attributes or the AD team will not maintain them, the SID-based approach avoids a dependency on that data. Auto private groups also depend on the chosen range, so review how default groups are created for AD users in your test environment. Record the decision in writing with the AD and Linux owners, since changing ranges later can leave file ownership and existing sessions out of step with the new numbers.
SID mapping versus POSIX attributes compared
SID-based ranges (ipa-ad-trust) derive UIDs and GIDs from each user's and group's Windows security identifier. FreeIPA computes the numbers on its side, so AD does not need to hold any Linux-specific value. POSIX-based ranges (ipa-ad-trust-posix) take the UID and GID values that AD already stores in POSIX attributes, so the numbers come from the directory that the AD team administers. The two paths can produce different numbers for the same person, and a host enrolled under one path will not automatically follow the other. Confirm in the trust documentation for your release exactly how each range type builds IDs.
- Source of the number: SID-based IDs are computed by FreeIPA, while POSIX-based IDs are read from AD attributes.
- Stability: a computed ID stays fixed while the SID stays the same, and a POSIX ID changes whenever the AD attribute changes.
- Collision handling: confirm how each range type avoids overlap with local IdM ranges and with other trusts.
- Range sizing: confirm the base and size of the range you plan, because they limit how many AD objects can be mapped.
- Existing file ownership: Linux files already owned by assigned numbers need a plan before any range change.
Check: record the exact UID and GID that a sample AD user receives under each option, then confirm that the numbers match your current file ownership.
A SID-based range depends on the trusted domain's SIDs and reads no POSIX attributes, so the AD schema and user records can stay as they are. A POSIX-based range depends on UID and GID attributes being present, populated and consistent for every user and group in scope. The FreeIPA trust documentation lists the trust prerequisites, but the attribute coverage is a question for your own AD forest. Gaps in that data show up as lookup failures or incorrect ownership on Linux, often long after the trust goes live.
- Schema and population: the POSIX attributes must exist in the AD schema and carry values for each account that needs Linux access.
- Data quality: blank, duplicate or conflicting values cause resolution failures or wrong file ownership.
- Coverage across domains: users in every trusted domain need valid values, so test each domain separately.
- Ownership of the data: the AD team controls the values, which means the IdM team depends on their change process.
- Attributes exposed through the trust: confirm which attributes IdM reads for each range type in your release.
Check: query the POSIX attributes for a representative sample of users in every domain before you choose the POSIX option.
The two range types respond differently when AD administrators edit or replace accounts. A SID-based ID does not move when someone edits a POSIX attribute, because that attribute is not an input. It can still change if an account is deleted and recreated, since the new account carries a new SID. A POSIX-based ID follows the AD attribute, so an edit can change the UID or GID that IdM serves to Linux hosts. Confirm in the trust documentation for your release how each option handles these events, and test them before production.
- Attribute edits: a POSIX change in AD can alter the IDs served to clients, with effects on running sessions and file ownership.
- Account recreation: a recreated AD account gets a new SID, so SID-based IDs for that user can change.
- Group changes: a GID change on an AD group affects any sudo or access rule that depends on that group.
- Change control: agree a review step with the AD team so that POSIX attribute edits reach Linux only after the IdM team has checked the impact.
- Client caching: SSSD caches identity data, so confirm the expiry behavior on clients before testing an ID change.
Check: make a POSIX attribute change in a non-production trust and confirm what each client returns after its cache refreshes.
The better fit depends on who owns Linux identity data in your organization. SID-based ranges suit estates where AD users mainly work on Windows, where the AD team does not maintain Unix attributes, or where Linux access is a secondary requirement. POSIX-based ranges suit estates where AD is already the system of record for UIDs and GIDs, where those numbers already appear in file systems, backups or application data, and where the AD team keeps the values accurate. Multi-forest and multi-site designs add further conditions that you should confirm before deciding.
- Windows-first estates: SID-based ranges usually need less coordination with the AD team.
- Unix-in-AD estates: POSIX-based ranges keep existing numbers stable when AD already holds them.
- Multi-forest or multi-site designs: confirm how each range type behaves across forests and sites in your release.
- Shared storage and NFS exports: numbers already written to storage must be reproduced by whichever option you pick.
- Regulated environments: record the choice, its owner and its change process in your data and access documentation.
Check: compare your existing file ownership and AD attribute coverage against each option before you decide.
Auto private groups (APG) give each user a private primary group, so that file ownership does not depend on a shared group. For AD users, the open question is which group becomes the primary group and how that choice interacts with the range type. The primary group recorded in AD, the group generated by FreeIPA and the GID derived from the range can differ, so the combination needs testing. Confirm the defaults and the behavior for your release in the trust documentation before you rely on group-based file ownership.
- What APG provides: a per-user primary group that gives each user a distinct GID for file ownership.
- AD primary groups: AD users already have a primary group in AD, and you need to confirm how IdM presents it when APG is in use.
- Interaction with range type: the GID for the private group may be derived differently under the SID and POSIX options.
- Shared group ownership: files owned by shared groups depend on which primary group a user is assigned.
- Reversibility: changing the primary group or APG settings later affects group membership and group-owned files.
Check: create a test AD user, log in on an enrolled host and confirm that the UID, primary GID and group list match your design.
How SID-derived IDs and AD POSIX values reach Linux hosts
With the SID mapping option, AD does not supply a UID or GID to Linux. When the trust is in place, FreeIPA receives each AD user's Windows SID and derives a POSIX UID and GID from a range it allocated for that trust. The same SID maps to the same number on every host in the deployment, but the number depends on the range layout, so it is only as stable as the range. With the POSIX option, FreeIPA reads the uidNumber and gidNumber values that the AD team has already stored on user and group objects. The Linux identity then follows whatever the AD team maintains. Before choosing, confirm which POSIX attributes are populated for your AD users and groups, whether they are unique across the forest, and who will be responsible for keeping them correct after go-live.
SSSD on each enrolled client does not perform the mapping itself. It asks the IdM server for the user and receives the name, UID, GID, home directory and shell, then caches the result so login works when the server is unreachable. AD groups appear in IdM as external groups, and their GIDs follow the same option as the users. Private groups need separate attention. Auto private groups create a per-user primary GID, so a user from the SID range and a group from AD POSIX data can collide if the numbers overlap. Check that the primary GID of each AD user matches a group that exists in the chosen source, and confirm how the AD team handles group GIDs that other systems already use.
Verify the result on at least two hosts with id and getent passwd for test users from each side of the trust, and compare the numbers. Use ipa idrange-find to review the ranges on the IdM side, and clear cached entries with sss_cache after any change so you do not mistake stale data for a fault. Plan for the lock-in: once users own files, home directories and cron jobs under a given UID, a later switch from one option to the other means renumbering those objects. Record the chosen option, the ranges and a test list of expected IDs, and treat any change to them as a migration with its own sign-off.
Planning the ID range before creating the AD trust
This sequence settles how AD users will receive UIDs and GIDs before any trust exists, so the range choice, its size and its boundaries are agreed and tested while they are still cheap to change.
Inventory AD POSIX attribute coverage
Ask the AD team to list which users and groups already carry POSIX attributes such as uidNumber, gidNumber, loginShell and unixHomeDirectory, and which Linux-facing objects are missing them. Record whether those values are consistent, unique and maintained by a process your team can rely on. Done means you hold a written inventory with counts by object type and a clear answer on whether POSIX values are complete enough to use. Treat any gaps or conflicts as inputs to the next step, not as problems to fix later in FreeIPA.
Choose the range type and size
Decide between an ipa-ad-trust range, which assigns IDs derived from each user's SID, and an ipa-ad-trust-posix range, which reads the POSIX attributes already stored in AD. Consider how many AD users and groups will log in to Linux, whether AD administrators will maintain UID values, and how often new domains or forests may join. Confirm the exact range types and options against the FreeIPA Trusts documentation and your installed version before you commit. Done means a written decision record names the range type, the expected population and the reason for the choice.
Reserve non-overlapping ID space
Agree the numeric ID range with the Linux team and confirm it does not overlap any local IPA range, any existing NIS or LDAP IDs, system accounts, or ranges already used by other trusted domains. Include headroom for growth, because changing a range after users have files and processes tied to their IDs is the hard part. Ask the AD team to confirm that no SID-based or POSIX-based value falls inside the chosen span. Done means a reviewed range table exists with start, size and owner for every entry.
Confirm trust and DNS prerequisites
Check that the IPA domain uses a DNS name that does not overlap any domain in the AD forest, as the FreeIPA Trusts page requires, and that DNS resolution works in both directions for the AD domain and the IPA domain. Confirm the trust direction and the AD functional levels with the AD team, and agree who will run each side of the trust commands. Done means both teams have signed off on naming, forward zones and resolution tests from both sides.
Create the trust with the agreed range
Create the trust using the range type and boundaries from the earlier decision records, and capture the command output and the resulting range object in your change log. Confirm that the range shows the expected type, start and size in the IPA configuration, and that no error is reported about overlaps. Done means the trust and its ID range exist exactly as documented, with a rollback plan stored alongside the change record.
Verify getent output on a test host
On an enrolled Linux test host, run getent passwd and getent group for a known AD user and a known AD group, then compare the returned UID, GID, home directory and shell with the values agreed in the inventory. Repeat for a user with and without POSIX attributes, and for a group that is not yet in the range. Done means every test account resolves to the expected ID, and any mismatch is traced to its source before rollout continues.
Confirm SSSD lookups and login behavior
On the same test host, check SSSD cache and lookups for the test accounts, confirm that the sssd service is running and that logs show no ID mapping errors, and test an SSH login with a test AD user. Check that auto private groups behave as your decision record states, and that the home directory and shell match policy. Done means SSSD returns stable results after a cache clear, and the AD team confirms the test accounts and their attributes match what they expect.
Security risks in ID range design
The ID range decision shapes who gets which UID and GID on every Linux host, so mistakes are security problems, not just housekeeping. The risks below share one root: an identifier that looks stable but is not controlled by the team that depends on it. Each card names the control or review step that keeps the mapping predictable.
Overlapping ID ranges
Two ranges that cover the same numeric IDs can give one Linux UID to two different identities, so file ownership and sudo rules may apply to the wrong person. Check every range in the IdM topology before a trust is created, including ranges left over from earlier trusts or from a WinSync setup. Compare the output of the range listing command on each server and confirm that no two ranges overlap with each other or with local system accounts on enrolled hosts. Record the range boundaries in your change record so later additions get checked against them.
UID reuse across domains
When a UID already used by a local account or another domain is handed to an AD user, file permissions and process ownership can cross identity boundaries. This risk is easy to miss because the numbers look valid in isolation. Before enabling a range, inventory UIDs and GIDs on hosts that will be enrolled, including service accounts, and confirm the range starts above them. Treat any reuse found during discovery as a blocking finding, not a note for later cleanup.
Over-broad access through group mapping
AD groups that are mapped to Linux groups, or used as external group members in HBAC and sudo rules, can grant far more access than the original AD group was meant to give. A broad group such as one that contains all domain users will carry its privileges onto every host it reaches. Review each AD group before it is referenced in policy, and confirm which hosts and commands each rule covers. Test access with a representative account from each group before the rule goes live.
Silent POSIX value changes in AD
With POSIX attributes read from AD, the UID, GID, shell and home directory come from values that AD administrators can edit. A change made for an unrelated reason, such as a template update or a bulk import, can move a user to another UID without any FreeIPA change. Ask the AD team to restrict edit rights on these attributes and to route changes through a ticket. On the IdM side, monitor UID changes for existing users and alert when a mapped value differs from the value recorded at enrollment.
Auto private group side effects
Auto private groups give each user a private primary group, and the GID assigned to it follows the same range logic as the UID. If the GID space is not planned with the UID space, private groups can collide with groups that already own shared directories. Confirm how private group GIDs are assigned for AD users under the chosen range type, and check that shared group GIDs fall outside the generated range. Review this setting before the first AD user logs in, because changing it later affects file ownership on existing hosts.
Range changes after first login
Once AD users have logged in and created files, their UIDs and GIDs are recorded on disk and in caches. Altering the range or the attribute source later can leave files owned by numbers that no longer resolve to the same user. Lock the design through a documented review before the first production login, and keep a written rollback plan for hosts that already have data. Confirm with your FreeIPA support contact how a range repair would be handled in your version before you depend on one.
Questions teams ask before changing AD ID mapping
How much effort does choosing between SID mapping and POSIX attributes take?
The decision itself is short, but the analysis behind it is not. Effort depends on how many AD users and groups need Linux access, whether AD already holds reliable uidNumber and gidNumber values, and how many hosts will need different identity settings. Teams that have not inventoried their AD POSIX attributes usually spend the most time on that inventory. Ask any partner to scope the discovery work separately from the build, and to state which AD and Linux systems they expect to review. No duration is given here because the researched facts do not supply one. The main effort drivers are the size of the AD forest, the state of existing POSIX data, and the number of Linux hosts that rely on the result.
Can our own team decide between SID mapping and POSIX attributes internally?
Yes, if the team has someone who understands both Kerberos realms and AD schema, and who can test the result on a non-production FreeIPA server. The choice turns on three questions: whether AD POSIX attributes are maintained and trusted, whether Linux UIDs must match an existing system, and whether any hosts need per-host overrides. Internal teams often underestimate the cross-team coordination, since the AD administrators own the attributes that the POSIX option reads. A partner can add an outside review of the decision record, but the decision needs an owner inside your organization.
What do AD and Linux administrators need to provide for this decision?
AD administrators need to confirm the forest and domain structure, whether users and groups carry uidNumber and gidNumber values, and who is allowed to change those attributes. Linux administrators need to list the hosts and services that depend on existing UIDs and GIDs, file ownership on shared storage, and any sudo or access rules that refer to numeric IDs. Both teams should agree on who owns ID range creation and who approves changes. Collect this before any trust or range is created, because the inventory determines which option is safe.
Why is changing the ID range later so difficult in FreeIPA?
Once users have logged in and received UIDs and GIDs, those numbers are stored on Linux file systems, in home directories, in process ownership and in configuration. Changing a range later means reassigning IDs for existing users and groups and checking every host, share and backup that recorded the old values. FreeIPA provides an ipa-idrange-fix tool in the 4.13.0 release, which helps repair certain range problems, but it does not replace a planned mapping. Treat the first choice as close to permanent and document the reasoning, the range sizes and the expected owners before the first AD user logs in.
What does a DeployOpen engagement cover for ID range design?
A DeployOpen engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this decision, the scope can include reviewing the AD attributes and Linux host inventory, recommending a range and mapping approach, designing the ID views the environment needs, and testing the result on a non-production FreeIPA deployment in your infrastructure. The written scope sets what is excluded, such as changes to AD itself. A quote follows from that scope. DeployOpen does not publish a price list.
What should we ask a partner before agreeing to a quote?
Ask for the written scope, the list of systems the partner will access, and the deliverables that record the decision. Ask how they will test ID mapping on non-production servers and how they will verify that existing Linux file ownership is unaffected. Ask who on your side must approve the range design, and whether the quote covers follow-on work such as ID views or trust configuration. Confirm backup steps before any change, since the FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Confirm also whether support after handover is a separate retainer.
Does FreeIPA's open-source license affect the cost of this decision?
FreeIPA is licensed under GPL-3.0-or-later and is a community project with no paid edition of its own. The software itself carries no license fee. Cost comes from the people who plan, build, test and run the deployment, plus the infrastructure it runs on. Confirm with your own legal team how the license applies to any custom work you commission, and confirm with the partner which parts of the deliverables you will own.
Why changing ID ranges after go-live is hard
Once AD users have UIDs and GIDs on your Linux hosts, changing the mapping later is a data migration, not a configuration edit. Every file an AD user owns, every home directory created under a UID, and every process or cron job that runs as that number carries the old ID. If the trust later assigns a different UID to the same SID, the user's own files appear owned by nobody they recognize, and access checks that rely on ownership or ACLs start failing. Before go-live, list where AD-derived IDs already exist: home directories on NFS or local disks, backup catalogs, container volumes, and application databases that store numeric IDs.
Plan for three kinds of cleanup. The first is re-owning files and directories, which means mapping old UIDs and GIDs to new ones on each host and each file server, usually with a scripted chown pass guided by a mapping table. The second is recreating or relocating home directories and keeping SSSD caches from pinning stale IDs on clients. The third is repairing the directory itself: duplicate or conflicting ID ranges, and users whose stored IDs no longer match the range they should fall in. For the directory side, the FreeIPA 4.13.0 release notes list an ipa-idrange-fix tool. Treat it as a repair aid to confirm against your version and your exact symptoms, not as a full fix for a changed range, and test it on a copy of the topology first.
