Active Directory Trusts

Overview

Active Directory trusts enable seamless integration between FreeIPA and Microsoft Active Directory domains, allowing AD users to authenticate to IPA-managed systems using their existing Windows credentials. Trust relationships establish cross-realm Kerberos authentication where AD users can access IPA resources without requiring duplicate accounts, while maintaining separate identity management in each domain.

IPA supports trusts with Active Directory domains running Windows Server 2008 or later with domain functional level 2008+. Trust establishment creates Kerberos cross-realm principals, configures ID mapping for converting Windows SIDs to POSIX UIDs/GIDs, and enables SSSD on IPA clients to resolve AD users and groups. AD users gain access to Linux resources while IT maintains a single source of truth for Windows identities in Active Directory.

Trust relationships can be one-way (AD users access IPA resources only) or two-way (bidirectional access), and can be forest-level (transitive across all domains in AD forest) or external (limited to specific domain). Trust establishment requires AD Domain Administrator credentials and proper DNS configuration enabling service discovery between domains. Once established, HBAC and sudo rules can reference AD users and groups, enabling policy-based access control for federated identities.

Prerequisites and Requirements

DNS Configuration: Both IPA and AD domains must have properly configured DNS with SRV records enabling service discovery. IPA DNS servers must be able to resolve AD domain controllers, and AD DNS must resolve IPA servers. Conditional forwarders or bidirectional DNS trust simplifies this requirement.

Kerberos Realm Configuration: Kerberos realms must be properly configured on both sides. IPA’s realm should match its DNS domain (uppercased), and AD’s realm similarly matches its domain. Realm trust principals enable cross-realm authentication.

Windows Server Version: Active Directory must run Windows Server 2008 or later with domain functional level 2008+. Older versions lack necessary trust protocols and Kerberos extensions for IPA integration.

ipa-adtrust-install: The IPA server must have AD trust support installed via ipa-adtrust-install. This configures Samba integration, creates the local SID/NetBIOS name, and prepares the domain for trust establishment.

Administrator Credentials: Trust establishment requires Active Directory Domain Administrator credentials to create the trust relationship from the AD side. The IPA admin performs configuration on the IPA side.

Firewall Configuration: Required ports (Kerberos 88, LDAP 389/636, Samba 139/445, etc.) must be open between IPA servers and AD domain controllers.

Trust Types and Directionality

One-Way Trusts (default): AD users can access IPA resources, but IPA users cannot access AD resources. This asymmetric trust suits scenarios where Linux/UNIX infrastructure needs AD user integration but Windows systems don’t need IPA user access.

Two-Way Trusts (--two-way): Bidirectional trust allowing both AD users to access IPA resources and IPA users to access AD resources. This comprehensive integration enables full cross-domain access in both directions.

Forest Trusts (default for AD forests): Transitive trust across all domains in the AD forest. When trust is established with the forest root domain, users from any domain in the forest can authenticate to IPA (subject to transitivity rules).

External Trusts (--external): Non-transitive trust limited to the specific AD domain. Users from child domains in the AD forest cannot access IPA resources. External trusts suit scenarios requiring strict control over which AD domains have access.

SID Mapping and ID Ranges

Security Identifier (SID) mapping converts Windows SIDs to POSIX UIDs and GIDs required for UNIX/Linux file permissions and process ownership. IPA allocates an ID range for each trusted domain, algorithmically deriving UID/GID from SID components.

ID ranges are configured during trust establishment using --base-id (starting ID) and --range-size (number of IDs). If not specified, IPA automatically allocates ranges. Range type (--range-type) determines the SID-to-UID mapping algorithm: ipa-ad-trust (default, algorithmic), ipa-ad-trust-posix (use existing POSIX attributes from AD).

SID-to-UID mapping is deterministic and consistent across all IPA clients, ensuring AD users receive the same UID regardless of which IPA client they authenticate to. This consistency is critical for NFS, file sharing, and process ownership.

External Group Mapping

AD users cannot directly join POSIX groups in IPA. Instead, external group mapping creates a two-tier structure: external non-POSIX groups contain AD SIDs, and POSIX groups contain external groups as members. When AD users authenticate, SSSD resolves their SID membership in external groups and grants effective POSIX group membership.

The mapping process:

Create external non-POSIX group (group-add --external)
Add AD users/groups by SID to external group (group-add-member --external)
Create POSIX group for actual authorization
Add external group to POSIX group as member

This indirection enables AD group membership to grant POSIX group privileges, allowing HBAC rules, sudo rules, and file permissions to reference POSIX groups that include AD users through external mapping.

DNS Integration

Trust establishment and operation depend heavily on DNS service discovery. AD clients locate domain controllers via DNS SRV records (_ldap._tcp, _kerberos._tcp, etc.). IPA clients similarly use DNS to locate IPA servers and AD domain controllers for cross-realm authentication.

Proper DNS configuration is the most common trust establishment pain point. Verify:

IPA can resolve AD SRV records: dig -t SRV _ldap._tcp.dc._msdcs.ad.domain.com
AD can resolve IPA SRV records: dig -t SRV _kerberos._tcp.ipa.domain.com
Conditional forwarders or stub zones correctly route queries

DNS misconfigurations cause cryptic errors during trust establishment and authentication. Always validate DNS before troubleshooting more complex trust issues.

Best Practices

Test in non-production first: Establish test trusts in lab environments before production deployment. Trust configuration errors can be difficult to undo cleanly.

Use one-way trusts when possible: Bidirectional trusts expand attack surface. If IPA users don’t need AD resource access, use default one-way trusts.

Plan ID range allocation carefully: Ensure ID ranges don’t overlap with existing local IDs or other trust ranges. Ranges cannot be easily changed after trust establishment.

Document external group mappings: Maintain clear records of which AD groups map to which POSIX groups. This mapping becomes complex in large environments.

Monitor trust health: Regularly verify trust status, password synchronization, and cross-realm authentication functionality.

Coordinate with AD administrators: Trust establishment impacts both domains. Work closely with AD team to schedule changes and troubleshoot issues.

Configure conditional forwarders: Rather than complex DNS delegation, use conditional forwarders in AD DNS forwarding IPA domain queries to IPA DNS servers, and vice versa.

Limit AD group usage in HBAC/sudo: Prefer IPA groups in policies when possible. AD group resolution adds latency and depends on trust availability.

Test fail-over scenarios: Verify behavior when AD domain controllers are unreachable. SSSD caching should enable continued operation, but test to confirm.

Plan for trust migration: If migrating users from AD to IPA, plan for gradual transition. Trusts enable coexistence during migration periods.

Kerberos Cross-Realm Authentication

Trust relationships establish Kerberos cross-realm authentication enabling AD users to obtain IPA service tickets:

Authentication flow:

AD user authenticates to AD KDC with password/smart card
User obtains AD Ticket Granting Ticket (TGT)
User requests access to IPA resource
SSSD requests cross-realm TGT from AD KDC for IPA.REALM
AD KDC issues inter-realm TGT (krbtgt/IPA.REALM@AD.REALM)
SSSD presents inter-realm TGT to IPA KDC
IPA KDC validates trust, issues service ticket for IPA resource
User accesses IPA resource with service ticket

Cross-realm principals:

krbtgt/IPA.REALM@AD.REALM - AD to IPA cross-realm key (one-way)
krbtgt/AD.REALM@IPA.REALM - IPA to AD cross-realm key (two-way only)

These shared secret principals enable KDCs to validate cross-realm tickets. Trust establishment creates these principals automatically.

Trust password synchronization:

Trust passwords change periodically (similar to computer account passwords)
AD initiates password changes; IPA must accept updates
Mismatched trust passwords break cross-realm authentication
Use trust-add to reset trust relationship if passwords desync

SID Blacklisting

SID blacklisting prevents specific AD users or groups from accessing IPA resources:

Use cases:

Block privileged AD groups from IPA access (Domain Admins, Enterprise Admins)
Prevent specific compromised accounts from authentication
Enforce separation of duties between AD and IPA administration

Blacklist types:

Incoming (--sid-blacklist-incoming): Block AD SIDs from accessing IPA resources
Outgoing (--sid-blacklist-outgoing): Block IPA SIDs from accessing AD resources (two-way trusts)

Well-known SID suffixes:

S-1-5-21-<domain>-512  - Domain Admins
S-1-5-21-<domain>-519  - Enterprise Admins
S-1-5-21-<domain>-544  - Administrators (local)
S-1-5-32-544           - BUILTIN\Administrators

Example blacklisting Domain Admins from IPA access:

# Get AD domain SID
ipa trust-show ad.example.com | grep "Domain Security Identifier"

# Construct Domain Admins SID (domain SID + -512)
# If domain SID is S-1-5-21-123456789-234567890-345678901
# Domain Admins SID is S-1-5-21-123456789-234567890-345678901-512

ipa trust-mod ad.example.com \
    --sid-blacklist-incoming="S-1-5-21-123456789-234567890-345678901-512"

Forest Trust Transitivity

Forest trusts enable transitive authentication across multiple AD domains:

Trust topology:

AD Forest: CORP.EXAMPLE.COM
├── CORP.EXAMPLE.COM (root domain)
├── EMEA.CORP.EXAMPLE.COM (child)
└── APAC.CORP.EXAMPLE.COM (child)

IPA trusts CORP.EXAMPLE.COM (forest root)
→ Users from CORP, EMEA, and APAC can all access IPA

Trust path resolution:

User from EMEA.CORP.EXAMPLE.COM requests IPA access
SSSD queries IPA for trust information
IPA recognizes EMEA as child of trusted forest root CORP
Kerberos constructs trust path: EMEA → CORP → IPA
Multiple cross-realm tickets obtained (transitive)
User gains access via forest trust transitivity

External trusts break transitivity:

# External trust: only CORP.EXAMPLE.COM users allowed
ipa trust-add corp.example.com --external

# EMEA and APAC users cannot access IPA (non-transitive)

Integration with Other IPA Components

ID Ranges (idrange-*): Each trust requires an ID range allocating UID/GID space for SID mapping. Range management is critical for trust operation.

External Groups (group-*): External group membership enables AD users to gain POSIX group membership for authorization contexts.

HBAC Rules (hbacrule-*): HBAC rules can target external groups containing AD users, enabling access control for federated identities.

Sudo Rules (sudorule-*): Sudo rules can reference external groups, granting sudo privileges to AD users.

SSSD: SSSD on IPA clients handles AD user resolution, SID-to-UID mapping, and cross-realm authentication.

Global Trust Configuration (trustconfig-*): Global settings control fallback primary groups and trust-wide parameters.

Certificate Mapping (certmap-*): Certificate mapping rules enable AD users to authenticate with certificates via Default Trust View.

ID Views (idview-*): Default Trust View allows overriding AD user attributes (UID, home directory, shell) across all IPA clients.

Use Cases

Basic AD User Integration

Scenario: Enable AD users to access IPA-managed Linux servers using AD credentials.

Solution:

# 1. Install AD trust support on IPA server
ipa-adtrust-install

# 2. Establish trust with AD domain
ipa trust-add ad.example.com \
    --admin Administrator \
    --password

# 3. Create external group for AD users
ipa group-add ad_linux_users_external --external

# 4. Add AD group to external group
ipa group-add-member ad_linux_users_external \
    --external 'AD\Domain Users'

# 5. Create POSIX group
ipa group-add ad_linux_users --desc "AD users with Linux access"

# 6. Link external group to POSIX group
ipa group-add-member ad_linux_users \
    --groups ad_linux_users_external

# 7. Create HBAC rule for AD users
ipa hbacrule-add allow_ad_users \
    --desc "Allow AD users to access Linux servers"
ipa hbacrule-add-user allow_ad_users --groups ad_linux_users
ipa hbacrule-add-host allow_ad_users --hosts linux01.ipa.example.com

# AD users can now SSH to linux01 using AD credentials

Multi-Forest Environment

Scenario: Trust multiple AD forests for different business units.

Solution:

# Trust forest A (corporate)
ipa trust-add corporate.example.com --admin admin@corporate.example.com

# Trust forest B (subsidiary)
ipa trust-add subsidiary.example.net --admin admin@subsidiary.example.net

# Create separate ID ranges if auto-allocation doesn't suffice
ipa idrange-add corporate_trust_range \
    --base-id 800000 \
    --range-size 200000 \
    --dom-sid=S-1-5-21-123-456-789

ipa idrange-add subsidiary_trust_range \
    --base-id 1000000 \
    --range-size 200000 \
    --dom-sid=S-1-5-21-987-654-321

# Each forest's users receive non-overlapping UIDs

AD Admin Separation

Scenario: Grant AD users sudo access on Linux, but prevent AD Domain Admins from automatically gaining root.

Solution:

# Establish trust
ipa trust-add ad.example.com --admin Administrator

# Get Domain Admins SID
ipa trust-show ad.example.com  # Note domain SID
# Construct Domain Admins SID by appending -512

# Blacklist Domain Admins
ipa trust-mod ad.example.com \
    --sid-blacklist-incoming="S-1-5-21-<domain-sid>-512,S-1-5-21-<domain-sid>-519"

# Create controlled Linux admin group
ipa group-add linux_admins_external --external
ipa group-add-member linux_admins_external \
    --external 'AD\Linux Administrators'

ipa group-add linux_admins --desc "Controlled Linux administrators"
ipa group-add-member linux_admins --groups linux_admins_external

# Create sudo rule for Linux admins only
ipa sudorule-add linux_admin_sudo
ipa sudorule-add-user linux_admin_sudo --groups linux_admins
ipa sudorule-mod linux_admin_sudo --cmdcat=all

# AD\Linux Administrators get sudo; Domain Admins blocked

External Trust for Single Domain

Scenario: Trust specific AD domain without granting access to child domains.

Solution:

# External trust (non-transitive)
ipa trust-add partner.external.com \
    --external \
    --admin Administrator@partner.external.com

# Only partner.external.com users can access IPA
# Child domains in partner.external.com forest cannot access

Two-Way Trust for IPA User AD Access

Scenario: Enable IPA users to access Windows file shares in AD.

Solution:

# Establish two-way trust
ipa trust-add ad.example.com \
    --two-way \
    --admin Administrator

# IPA users can now authenticate to AD resources
# AD users can authenticate to IPA resources (bidirectional)

Examples

Trust Establishment

Establish trust with AD domain using admin credentials:

ipa trust-add ad.example.com \
    --type ad \
    --admin Administrator \
    --password

Establish trust prompting for AD admin password:

ipa trust-add ad.example.com --admin Administrator@ad.example.com
# Prompted for password

Establish trust specifying AD domain controller:

ipa trust-add ad.example.com \
    --admin Administrator \
    --server dc01.ad.example.com \
    --password

Establish two-way (bidirectional) trust:

ipa trust-add ad.example.com \
    --two-way \
    --admin Administrator \
    --password

Establish external (non-transitive) trust:

ipa trust-add external.corp.com \
    --external \
    --admin Administrator@external.corp.com \
    --password

Establish trust with custom ID range:

ipa trust-add ad.example.com \
    --admin Administrator \
    --base-id 900000 \
    --range-size 200000

Establish trust using POSIX attributes from AD:

ipa trust-add ad.example.com \
    --admin Administrator \
    --range-type ipa-ad-trust-posix

Re-establish trust (updates trust password):

# Safe to run multiple times against same domain
ipa trust-add ad.example.com \
    --admin Administrator \
    --password

Managing Trusts

List all trust relationships:

ipa trust-find
ipa trust-find --all
ipa trust-find --pkey-only  # Realm names only

Find trusts by domain SID:

ipa trust-find --sid S-1-5-21-123456789-234567890-345678901

Find trusts by NetBIOS name:

ipa trust-find --flat-name ADCORP

Show trust details:

ipa trust-show ad.example.com
ipa trust-show ad.example.com --all --raw

View trust SID and NetBIOS name:

ipa trust-show ad.example.com | grep -E "(NetBIOS|SID)"

Delete trust relationship:

ipa trust-del ad.example.com

Modify trust to add SID blacklist:

ipa trust-mod ad.example.com \
    --sid-blacklist-incoming="S-1-5-21-<domain-sid>-512"

Add multiple SIDs to blacklist:

ipa trust-mod ad.example.com \
    --sid-blacklist-incoming="S-1-5-21-<domain-sid>-512,S-1-5-21-<domain-sid>-519"

Modify trust to add UPN suffixes:

ipa trust-mod ad.example.com \
    --upn-suffixes="alt.example.com,legacy.example.com"

Forest Domain Management

Fetch list of domains in trusted forest:

ipa trust-fetch-domains ad.example.com

Fetch domains with explicit credentials:

ipa trust-fetch-domains ad.example.com \
    --admin Administrator \
    --server dc01.ad.example.com

List domains in trusted forest:

ipa trustdomain-find ad.example.com
ipa trustdomain-find ad.example.com --all

Find specific domain in forest:

ipa trustdomain-find ad.example.com --domain child.ad.example.com

Show domain details:

ipa trustdomain-find ad.example.com --domain child.ad.example.com --all

Disable child domain access:

ipa trustdomain-disable ad.example.com child.ad.example.com

Re-enable child domain access:

ipa trustdomain-enable ad.example.com child.ad.example.com

Remove child domain from trust:

ipa trustdomain-del ad.example.com child.ad.example.com

External Group Mapping

Create external group for AD users:

ipa group-add ad_developers_external --external \
    --desc "External mapping for AD developers"

Add AD group to external group (using domain\group format):

ipa group-add-member ad_developers_external \
    --external 'AD\Developers'

Add AD group using SID:

ipa group-add-member ad_developers_external \
    --external 'S-1-5-21-123456789-234567890-345678901-1234'

Add individual AD user to external group:

ipa group-add-member ad_developers_external \
    --external 'AD\jdoe'

Create POSIX group and link external group:

ipa group-add ad_developers --desc "AD developers POSIX group"
ipa group-add-member ad_developers --groups ad_developers_external

View external group membership (shows SIDs):

ipa group-show ad_developers_external

Verify effective POSIX membership:

# On IPA client after AD user jdoe@ad.example.com logs in
id jdoe@ad.example.com
# Should show ad_developers group membership

Complex mapping example (multiple AD groups to one POSIX group):

# External groups
ipa group-add ad_admins_external --external
ipa group-add ad_senior_devs_external --external

# Add AD groups
ipa group-add-member ad_admins_external --external 'AD\Domain Admins'
ipa group-add-member ad_senior_devs_external --external 'AD\Senior Developers'

# POSIX group
ipa group-add linux_admins --desc "Unified Linux administrators"

# Link both external groups
ipa group-add-member linux_admins \
    --groups ad_admins_external,ad_senior_devs_external

# Members of either AD group gain linux_admins membership

Global Trust Configuration

Show global trust configuration:

ipa trustconfig-show
ipa trustconfig-show --type ad --all

View current fallback primary group:

ipa trustconfig-show --type ad | grep "Fallback primary group"

Change fallback primary group for AD users:

ipa trustconfig-mod --type ad \
    --fallback-primary-group "AD Linux Users"

Reset to default fallback group:

ipa trustconfig-mod --type ad \
    --fallback-primary-group "Default SMB Group"

HBAC and Sudo with AD Users

Create HBAC rule for AD users:

# Create external group mapping (prerequisite)
ipa group-add ad_ssh_users_external --external
ipa group-add-member ad_ssh_users_external --external 'AD\Linux SSH Users'
ipa group-add ad_ssh_users
ipa group-add-member ad_ssh_users --groups ad_ssh_users_external

# Create HBAC rule
ipa hbacrule-add allow_ad_ssh --desc "Allow AD users SSH access"
ipa hbacrule-add-user allow_ad_ssh --groups ad_ssh_users
ipa hbacrule-add-host allow_ad_ssh --hostgroups linux_servers
ipa hbacrule-add-service allow_ad_ssh --hbacsvcs sshd

Create sudo rule for AD administrators:

# External group mapping
ipa group-add ad_linux_admins_external --external
ipa group-add-member ad_linux_admins_external --external 'AD\Linux Admins'
ipa group-add ad_linux_admins
ipa group-add-member ad_linux_admins --groups ad_linux_admins_external

# Sudo rule
ipa sudorule-add ad_admin_sudo --desc "AD Linux admins sudo access"
ipa sudorule-add-user ad_admin_sudo --groups ad_linux_admins
ipa sudorule-add-host ad_admin_sudo --hostgroups linux_servers
ipa sudorule-mod ad_admin_sudo --cmdcat all
ipa sudorule-mod ad_admin_sudo --runasusercat all

Troubleshooting Workflows

Verify DNS configuration:

# From IPA server: resolve AD SRV records
dig -t SRV _ldap._tcp.dc._msdcs.ad.example.com
dig -t SRV _kerberos._tcp.dc._msdcs.ad.example.com
dig -t SRV _kerberos._tcp.ad.example.com

# From AD server: resolve IPA SRV records (requires AD admin access)
nslookup -type=SRV _ldap._tcp.ipa.example.com
nslookup -type=SRV _kerberos._tcp.ipa.example.com

Test Kerberos cross-realm authentication:

# On IPA client
kinit jdoe@AD.EXAMPLE.COM
klist
# Should show tickets from AD.EXAMPLE.COM realm

# Request cross-realm TGT
kvno host/linux01.ipa.example.com@IPA.EXAMPLE.COM
klist
# Should show cross-realm ticket krbtgt/IPA.EXAMPLE.COM@AD.EXAMPLE.COM

Verify AD user resolution on IPA client:

# Lookup AD user
getent passwd jdoe@ad.example.com
id jdoe@ad.example.com

# Lookup AD group
getent group 'domain users@ad.example.com'

# If resolution fails, check SSSD
sssctl domain-status ipa.example.com
sssctl user-checks jdoe@ad.example.com

Check trust relationship health:

# On IPA server
ipa trust-show ad.example.com

# Verify trust password
# If trust password is out of sync, re-run trust-add
ipa trust-add ad.example.com --admin Administrator

# Check SSSD trust resolution
sssctl domain-list
sssctl domain-status ad.example.com

Debug SSSD trust issues:

# Increase SSSD debug level
sssctl debug-level 6

# Check logs
tail -f /var/log/sssd/sssd_ipa.example.com.log
tail -f /var/log/sssd/sssd_ad.example.com.log

# Clear cache and retry
sssctl cache-expire --everything
systemctl restart sssd

# Test user lookup
getent passwd jdoe@ad.example.com

Verify ID range assignment:

# Show trust ID range
ipa idrange-find --all | grep -A10 "ad.example.com"

# Verify no overlap with other ranges
ipa idrange-find --all

# Check AD user UID assignment
id jdoe@ad.example.com
# UID should fall within trust ID range

Security Considerations

Trust expands attack surface: AD compromise can compromise IPA resources. Limit trust scope with external trusts and SID blacklisting.

SID blacklisting prevents privilege escalation: Always blacklist AD Domain Admins and Enterprise Admins from IPA access unless explicitly required.

One-way trusts reduce risk: Bidirectional trusts allow IPA compromise to affect AD. Use one-way trusts unless two-way is necessary.

External group visibility: External group SID membership visible to all authenticated IPA users. Don’t encode sensitive information in group names.

Trust password synchronization: Trust passwords change periodically. Monitor for desynchronization causing authentication failures.

DNS security: DNS spoofing can redirect clients to rogue KDCs. Use DNSSEC or secure network infrastructure between IPA and AD.

Cross-realm ticket interception: Kerberos tickets crossing realms are vulnerable to interception. Use encryption and secure networks.

SSSD offline cache: AD user credentials cached by SSSD for offline operation. Ensure SSSD cache encryption and permissions.

Firewall rules: Minimize port exposure between IPA and AD. Only allow necessary Kerberos (88), LDAP (389/636), Samba (139/445) traffic.

Audit external group membership: Regularly review which AD groups have POSIX group membership and what privileges those POSIX groups grant.

Operational Considerations

Coordinate with AD administrators: Trust establishment requires coordination. Schedule maintenance windows and communicate changes.

Test in non-production first: Trust configuration errors can affect both IPA and AD. Validate in lab before production deployment.

Plan ID range allocation carefully: ID ranges cannot be easily changed post-deployment. Ensure sufficient size and no overlaps.

Monitor trust health: Regularly verify trust relationship status, cross-realm authentication, and user resolution.

Document external group mappings: Maintain clear documentation of AD-to-POSIX group mappings as these become complex.

Implement HBAC for AD users: Don’t assume AD authentication implies authorization. Use HBAC to control AD user access.

Plan for AD forest changes: Adding/removing AD domains affects trust transitivity. Re-fetch domains after forest topology changes.

Handle trust password changes: Trust passwords rotate automatically. If sync fails, re-run trust-add to reset relationship.

Cache considerations: SSSD caches AD user/group data. Plan cache timeout and expiration strategies for security vs. performance.

Backup trust configuration: Document trust parameters (ID ranges, blacklists, external groups) for disaster recovery.

Troubleshooting

Trust establishment fails with DNS errors:

# Verify DNS resolution from IPA to AD
dig -t SRV _ldap._tcp.dc._msdcs.ad.example.com
dig ad.example.com

# Verify AD can resolve IPA
# (requires AD admin access)
nslookup ipa.example.com <AD-DNS-server>

# Configure conditional forwarders if resolution fails
# In AD DNS: Add conditional forwarder for ipa.example.com → IPA DNS servers
# In IPA DNS: Add forward zone for ad.example.com → AD DNS servers

AD users cannot authenticate to IPA clients:

# 1. Verify trust exists
ipa trust-show ad.example.com

# 2. Check SSSD domain configuration on client
sssctl domain-list  # Should include ad.example.com

# 3. Test user resolution
getent passwd jdoe@ad.example.com

# 4. If resolution fails, check SSSD logs
tail -f /var/log/sssd/sssd_ad.example.com.log

# 5. Verify Kerberos configuration
kinit jdoe@AD.EXAMPLE.COM
klist

# 6. Clear SSSD cache and retry
sssctl cache-expire --everything
systemctl restart sssd

AD group membership not reflecting in IPA:

# Verify external group configuration
ipa group-show ad_group_external

# Verify SID is correct
# Get AD group SID from AD admin or via:
# (on AD): Get-ADGroup "Group Name" | Select-Object SID

# Add with correct SID
ipa group-add-member ad_group_external \
    --external 'S-1-5-21-<correct-sid>'

# Verify POSIX group linkage
ipa group-show posix_group | grep "Member groups"

# Test effective membership on client
id aduser@ad.example.com

Trust password out of sync:

# Symptom: Cross-realm authentication fails with trust errors

# Re-establish trust (resets trust password)
ipa trust-add ad.example.com \
    --admin Administrator \
    --password

# Verify trust health
ipa trust-show ad.example.com

# Test authentication
kinit aduser@AD.EXAMPLE.COM

Child domain users cannot access IPA (forest trust):

# Refresh forest domain list
ipa trust-fetch-domains ad.example.com \
    --admin Administrator

# Verify child domain is enabled
ipa trustdomain-find ad.example.com

# If disabled, enable it
ipa trustdomain-enable ad.example.com child.ad.example.com

# Verify transitivity
ipa trust-show ad.example.com | grep -i external
# Should NOT show "external" for forest trusts

UID conflicts between AD users and IPA users:

# Check ID range allocation
ipa idrange-find --all

# Identify conflict
id conflicting-ipa-user
id aduser@ad.example.com
# If UIDs match but users are different, range overlap exists

# Solution: Delete trust, fix ID range, re-establish trust
ipa trust-del ad.example.com
ipa idrange-del AD.EXAMPLE.COM_id_range

# Re-create with non-conflicting range
ipa trust-add ad.example.com \
    --admin Administrator \
    --base-id 900000 \
    --range-size 200000

SID blacklist not working:

# Verify blacklist configuration
ipa trust-show ad.example.com --all | grep -i blacklist

# Ensure correct SID format
# Domain Admins SID: <domain-SID>-512
# Get domain SID from trust
ipa trust-show ad.example.com | grep "Domain Security Identifier"

# Update blacklist with correct SID
ipa trust-mod ad.example.com \
    --sid-blacklist-incoming="S-1-5-21-<domain-sid>-512"

# Clear SSSD cache for changes to take effect
sssctl cache-expire --everything

Performance issues with AD group resolution:

# Reduce AD group resolution frequency
# Edit /etc/sssd/sssd.conf on clients:
[domain/ipa.example.com]
entry_cache_timeout = 3600
ldap_purge_cache_timeout = 86400

# Restart SSSD
systemctl restart sssd

# Prefer IPA groups over AD groups in HBAC/sudo rules
# Convert frequently-checked AD groups to IPA-native groups with AD users

Old Basic Examples (for reference)

Establish cross-realm trust with Active Directory using AD administrator credentials:

 ipa trust-add --type=ad <ad.domain> --admin <AD domain administrator>            --password

List all existing trust relationships:

 ipa trust-find

Show details of the specific trust relationship:

 ipa trust-show <ad.domain>

Delete existing trust relationship:

 ipa trust-del <ad.domain>

Once trust relationship is established, remote users will need to be mapped to local POSIX groups in order to actually use IPA resources. The mapping should be done via use of external membership of non-POSIX group and then this group should be included into one of local POSIX groups.

Example

Establish cross-realm trust with Active Directory using AD administrator credentials:

ipa trust-add --type=ad <ad.domain> --admin <AD domain administrator>            --password

List all existing trust relationships:

ipa trust-find

Show details of the specific trust relationship:

ipa trust-show <ad.domain>

Delete existing trust relationship:

ipa trust-del <ad.domain>

Example

1. Create group for the trusted domain admins’ mapping and their local POSIX group:

ipa group-add --desc='<ad.domain> admins external map'            ad_admins_external --external
ipa group-add --desc='<ad.domain> admins' ad_admins

Add security identifier of Domain Admins of the <ad.domain> to the ad_admins_external group:

ipa group-add-member ad_admins_external --external 'AD\Domain Admins'

Allow members of ad_admins_external group to be associated with ad_admins POSIX group:

ipa group-add-member ad_admins --groups ad_admins_external

List members of external members of ad_admins_external group to see their SIDs:

ipa group-show ad_admins_external

GLOBAL TRUST CONFIGURATION

When IPA AD trust subpackage is installed and ipa-adtrust-install is run, a local domain configuration (SID, GUID, NetBIOS name) is generated. These identifiers are then used when communicating with a trusted domain of the particular type.

Show global trust configuration for Active Directory type of trusts:

ipa trustconfig-show --type ad

Modify global configuration for all trusts of Active Directory type and set a different fallback primary group (fallback primary group GID is used as a primary user GID if user authenticating to IPA domain does not have any other primary GID already set):

ipa trustconfig-mod --type ad --fallback-primary-group "another AD group"

Change primary fallback group back to default hidden group (any group with posixGroup object class is allowed):

ipa trustconfig-mod --type ad --fallback-primary-group "Default SMB Group"

Commands

trust-add

Usage: ipa [global-options] trust-add REALM [options]

Add new trust to use.

This command establishes trust relationship to another domain which becomes ‘trusted’. As result, users of the trusted domain may access resources of this domain.

Only trusts to Active Directory domains are supported right now.

The command can be safely run multiple times against the same domain, this will cause change to trust relationship credentials on both sides.

Note that if the command was previously run with a specific range type, or with automatic detection of the range type, and you want to configure a different range type, you may need to delete first the ID range using ipa idrange-del before retrying the command with the desired range type.

Arguments

Argument	Required	Description
`REALM`	yes	Realm name

Options

Option	Description
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--type TYPE`	Trust type (ad for Active Directory, default)
`--admin ADMIN`	Active Directory domain administrator
`--password PASSWORD`	Active Directory domain administrator’s password
`--server SERVER`	Domain controller for the Active Directory domain (optional)
`--trust-secret TRUST-SECRET`	Shared secret for the trust
`--base-id BASE-ID`	First Posix ID of the range reserved for the trusted domain
`--range-size RANGE-SIZE`	Size of the ID range reserved for the trusted domain
`--range-type RANGE-TYPE`	Type of trusted domain ID range, one of allowed values
`--two-way TWO-WAY`	Establish bi-directional trust. By default trust is inbound one-way only.
`--external EXTERNAL`	Establish external trust to a domain in another forest. The trust is not transitive beyond the domain.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trust-del

Usage: ipa [global-options] trust-del REALM [options]

Delete a trust.

Arguments

Argument	Required	Description
`REALM`	yes	Realm name

Options

Option	Description
`--continue`	Continuous mode: Don’t stop on errors.

trust-fetch-domains

Usage: ipa [global-options] trust-fetch-domains REALM [options]

Refresh list of the domains associated with the trust

Arguments

Argument	Required	Description
`REALM`	yes	Realm name

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--admin ADMIN`	Active Directory domain administrator
`--password PASSWORD`	Active Directory domain administrator’s password
`--server SERVER`	Domain controller for the Active Directory domain (optional)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trust-find

Usage: ipa [global-options] trust-find [CRITERIA] [options]

Search for trusts.

Arguments

Argument Required Description

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--realm REALM`	Realm name
`--flat-name FLAT-NAME`	Domain NetBIOS name
`--sid SID`	Domain Security Identifier
`--sid-blacklist-incoming SID-BLACKLIST-INCOMING`	SID blocklist incoming
`--sid-blacklist-outgoing SID-BLACKLIST-OUTGOING`	SID blocklist outgoing
`--timelimit TIMELIMIT`	Time limit of search in seconds (0 is unlimited)
`--sizelimit SIZELIMIT`	Maximum number of entries returned (0 is unlimited)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--pkey-only`	Results should contain primary key attribute only (“realm”)

trust-mod

Usage: ipa [global-options] trust-mod REALM [options]

Modify a trust (for future use).

Currently only the default option to modify the LDAP attributes is
available. More specific options will be added in coming releases.

Arguments

Argument	Required	Description
`REALM`	yes	Realm name

Options

Option	Description
`--sid-blacklist-incoming SID-BLACKLIST-INCOMING`	SID blocklist incoming
`--sid-blacklist-outgoing SID-BLACKLIST-OUTGOING`	SID blocklist outgoing
`--upn-suffixes UPN-SUFFIXES`	UPN suffixes
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--delattr DELATTR`	Delete an attribute/value pair. The option will be evaluated
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trust-show

Usage: ipa [global-options] trust-show REALM [options]

Display information about a trust.

Arguments

Argument	Required	Description
`REALM`	yes	Realm name

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trustconfig-mod

Usage: ipa [global-options] trustconfig-mod [options]

Modify global trust configuration.

Options

Option	Description
`--fallback-primary-group FALLBACK-PRIMARY-GROUP`	Fallback primary group
`--setattr SETATTR`	Set an attribute to a name/value pair. Format is attr=value.
`--addattr ADDATTR`	Add an attribute/value pair. Format is attr=value. The attribute
`--delattr DELATTR`	Delete an attribute/value pair. The option will be evaluated
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--type TYPE`	Trust type (ad for Active Directory, default)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trustconfig-show

Usage: ipa [global-options] trustconfig-show [options]

Show global trust configuration.

Options

Option	Description
`--rights`	Display the access rights of this entry (requires —all). See ipa man page for details.
`--type TYPE`	Trust type (ad for Active Directory, default)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.

trustdomain-del

Usage: ipa [global-options] trustdomain-del TRUST DOMAIN [options]

Remove information about the domain associated with the trust.

Arguments

Argument	Required	Description
`TRUST`	yes	Realm name

DOMAIN yes Domain name

Options

Option	Description
`--continue`	Continuous mode: Don’t stop on errors.

trustdomain-disable

Usage: ipa [global-options] trustdomain-disable TRUST DOMAIN [options]

Disable use of IPA resources by the domain of the trust

Arguments

Argument	Required	Description
`TRUST`	yes	Realm name

DOMAIN yes Domain name

trustdomain-enable

Usage: ipa [global-options] trustdomain-enable TRUST DOMAIN [options]

Allow use of IPA resources by the domain of the trust

Arguments

Argument	Required	Description
`TRUST`	yes	Realm name

DOMAIN yes Domain name

trustdomain-find

Usage: ipa [global-options] trustdomain-find TRUST [CRITERIA] [options]

Search domains of the trust

Arguments

Argument	Required	Description
`TRUST`	yes	Realm name

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--domain DOMAIN`	Domain name
`--flat-name FLAT-NAME`	Domain NetBIOS name
`--sid SID`	Domain Security Identifier
`--timelimit TIMELIMIT`	Time limit of search in seconds (0 is unlimited)
`--sizelimit SIZELIMIT`	Maximum number of entries returned (0 is unlimited)
`--all`	Retrieve and print all attributes from the server. Affects command output.
`--raw`	Print entries as stored on the server. Only affects output format.
`--pkey-only`	Results should contain primary key attribute only (“domain”)

Overview

Prerequisites and Requirements

Trust Types and Directionality

SID Mapping and ID Ranges

External Group Mapping

DNS Integration

Best Practices

Kerberos Cross-Realm Authentication

SID Blacklisting

Forest Trust Transitivity

Integration with Other IPA Components

Use Cases

Basic AD User Integration

Multi-Forest Environment

AD Admin Separation

External Trust for Single Domain

Two-Way Trust for IPA User AD Access

Examples

Trust Establishment

Managing Trusts

Forest Domain Management

External Group Mapping

Global Trust Configuration

HBAC and Sudo with AD Users

Troubleshooting Workflows

Security Considerations

Operational Considerations

Troubleshooting

Old Basic Examples (for reference)

Commands

trust-add

Arguments

Options

trust-del

Arguments

Options

trust-fetch-domains

Arguments

Options

trust-find

Arguments

Options

trust-mod

Arguments

Options

trust-show

Arguments

Options

trustconfig-mod

Options

trustconfig-show

Options

trustdomain-del

Arguments

Options

trustdomain-disable

Arguments

trustdomain-enable

Arguments

trustdomain-find

Arguments

Options

Related Topics