Domain Level

Overview

Domain Level is a compatibility mechanism in FreeIPA that controls which features are available across the entire IPA deployment. Similar to Active Directory functional levels, the IPA domain level ensures all servers in the topology support features before they become available for use.

Key Concepts:

• Version Gating: Domain level prevents use of features requiring newer IPA versions when older servers exist in the topology
• Irreversible: Raising domain level cannot be undone; servers running older versions cannot be added afterward
• Coordinated Upgrades: Enables phased server upgrades followed by feature activation
• Replication Compatibility: Ensures LDAP replication compatibility across all servers

Domain Level Progression:

• Level 0: Initial level, supports FreeIPA 4.0 and newer
• Level 1: Requires FreeIPA 4.3+, enables topology management, domain trust features
• Higher Levels: Future levels gate additional features as IPA evolves

Raising domain level is a critical operational decision requiring careful planning, testing, and coordination across the entire IPA infrastructure.

EXAMPLES

Check current domain level:

ipa domainlevel-get

Raise domain level to 1 (requires all servers running FreeIPA 4.3+):

ipa domainlevel-set 1

Verify all servers support target level before raising:

ipa server-find --all | grep -i version

Commands

domainlevel-get

Usage: ipa [global-options] domainlevel-get [options]

Query current Domain Level.

domainlevel-set

Usage: ipa [global-options] domainlevel-set LEVEL [options]

Change current Domain Level.

Arguments

Argument	Required	Description
LEVEL	yes	Domain Level

Use Cases

Enabling Topology Management After Infrastructure Upgrade

Organizations that upgraded all IPA servers from 4.2 to 4.3 or newer can raise domain level to 1 to enable modern topology management features, replacing legacy replication agreements with managed topology.

# Verify all servers are running FreeIPA 4.3 or newer
ipa server-find --all | grep "IPA version"

# Check current domain level
ipa domainlevel-get
# Output: Current domain level: 0

# Verify replication is healthy across all servers
ipa-replica-manage list
ipa-csreplica-manage list

# Raise domain level to 1
ipa domainlevel-set 1

# Verify level change
ipa domainlevel-get
# Output: Current domain level: 1

# Now topology management commands become available
ipa topologysegment-find
ipa topologysuffix-show domain

Phased Upgrade Planning with Feature Gate Management

Large deployments upgrade IPA servers in phases over weeks or months. Domain level remains at lower level during upgrade phase, then raised once all servers complete upgrade to enable new features.

# Before starting upgrades, document current state
ipa domainlevel-get > /tmp/pre-upgrade-level.txt
ipa server-find --all > /tmp/pre-upgrade-servers.txt

# Upgrade servers one by one (example for single server)
# On server to upgrade: dnf update ipa-server
# Restart services: ipactl restart

# After each upgrade, verify server health
ipa server-show server01.example.com

# Track upgrade progress
ipa server-find --all | grep -i version | sort | uniq -c

# Once all servers at 4.3+, raise domain level
ipa domainlevel-set 1

# Document post-upgrade state
ipa domainlevel-get > /tmp/post-upgrade-level.txt

Preventing Addition of Incompatible Replica Servers

After raising domain level, attempting to add replicas running older IPA versions will fail. This prevents topology inconsistencies and ensures all servers support required features.

# Domain level raised to 1 (requires FreeIPA 4.3+)
ipa domainlevel-get
# Output: Current domain level: 1

# Attempt to install replica on server running FreeIPA 4.2
# On old server: ipa-replica-install
# This will fail with version compatibility error

# Error message indicates minimum version requirement
# Must upgrade server to FreeIPA 4.3+ before replica installation

# Verify all existing replicas are compatible
ipa server-find --all | grep "IPA version"

Validating Domain Level Requirements Before Feature Implementation

Administrators planning to implement features requiring specific domain level can verify compatibility before proceeding with implementation projects.

# Check current domain level before planning trust implementation
ipa domainlevel-get

# If level 0, check if all servers support level 1
ipa server-find --all

# Review which servers need upgrades
ipa server-show server01.example.com --all | grep "Max domain level"

# Plan upgrade path to reach required level
# Document servers below minimum: FreeIPA < 4.3
# Schedule upgrades, then domain level raise
# Then proceed with trust configuration

Testing Domain Level Raise in Non-Production Environment

Before raising production domain level, organizations test the process in non-production environments to identify potential issues and develop procedures.

# In test environment, verify starting state
ipa domainlevel-get
ipa server-find --all | grep "IPA version"

# Document test procedure
# 1. Backup LDAP data
# 2. Raise domain level
# 3. Test all functionality
# 4. Verify replication
# 5. Test new features available at higher level

# Execute test domain level raise
ipa domainlevel-set 1

# Validate topology management works
ipa topologysegment-find domain
ipa topologysegment-find ca

# Test adding new segment (topology management feature)
ipa topologysegment-add domain test-segment \
  --leftnode=server1.example.com \
  --rightnode=server2.example.com

# Document any issues for production planning

Coordinating Domain Level Raise with Change Management

Enterprises with strict change management coordinate domain level raising with infrastructure teams, application owners, and stakeholders.

# Pre-change documentation
echo "Change ticket: CHG123456" > /tmp/domain-level-change.txt
ipa domainlevel-get >> /tmp/domain-level-change.txt
ipa server-find --all >> /tmp/domain-level-change.txt

# Scheduled maintenance window communication
# Subject: IPA Domain Level Upgrade - [Date/Time]
# Impact: Brief service interruption possible
# Rollback: Not possible - domain level raise is irreversible

# During maintenance window
ipa domainlevel-set 1

# Post-change validation
ipa domainlevel-get
ipa-replica-manage list  # Verify replication still working
ipa topologysegment-find domain  # Verify new features available

# Update documentation and close change ticket

Assessing Maximum Domain Level Capability Per Server

Understanding each server’s maximum supported domain level helps plan upgrade paths and identify servers requiring replacement or upgrade.

# Check maximum domain level each server supports
ipa server-find --all

# Review output for "Max domain level" attribute
# Example output:
#   Server name: server1.example.com
#   Max domain level: 1
#   Min domain level: 0
#   IPA version: 4.6.8

# Identify servers limiting domain level advancement
# Servers with lower "Max domain level" block raising domain level

# Plan upgrades or decommissioning for limiting servers

Rolling Back Planned Domain Level Raise Due to Compatibility Issues

Organizations may discover compatibility issues during testing requiring cancellation of planned domain level raise.

# During testing, discover application incompatibility with new features
# Decision: postpone domain level raise

# Current domain level remains unchanged
ipa domainlevel-get
# Output: Current domain level: 0

# No action needed - simply don't execute domainlevel-set

# Update project plan with revised timeline
# Schedule remediation of compatibility issues
# Plan new date for domain level raise after fixes

# Note: If already raised, cannot roll back
# This scenario only applies to planned-but-not-executed raises

Documenting Domain Level History for Compliance Audits

Compliance requirements may mandate documentation of infrastructure changes including domain level modifications for audit trails.

# Query current domain level for audit documentation
ipa domainlevel-get

# Review LDAP changelog for historical domain level changes
ldapsearch -Y GSSAPI -b "cn=changelog" \
  "(targetdn=cn=Domain Level,cn=ipa,cn=etc,dc=example,dc=com)" \
  changetime changeType changes

# Export domain level configuration
ipa domainlevel-get > /tmp/domain-level-$(date +%Y%m%d).txt

# Include in compliance documentation
# - Current domain level
# - Date of last change
# - Change authorization (ticket number)
# - Business justification
# - Validation results

Migrating Legacy Replication to Managed Topology

After raising domain level to 1, organizations can migrate from legacy manual replication agreements to modern managed topology segments.

# Before raising domain level, document legacy replication
ipa-replica-manage list > /tmp/legacy-replication.txt
ipa-csreplica-manage list >> /tmp/legacy-replication.txt

# Raise domain level to enable topology management
ipa domainlevel-set 1

# Legacy replication agreements automatically converted to topology segments
ipa topologysegment-find domain
ipa topologysegment-find ca

# Verify all replication paths are represented as segments
# Compare topology segments to legacy replication agreements

# New replication management uses topology commands
ipa topologysegment-add domain new-segment \
  --leftnode=server1.example.com \
  --rightnode=server3.example.com

# Legacy ipa-replica-manage commands deprecated at higher domain levels

Security Considerations

Irreversible Domain Level Raise Creates Rollback Limitations

Raising domain level cannot be undone. If compatibility issues or feature problems are discovered after raising domain level, downgrading is not possible without complete IPA reinstallation and data migration. This creates risk when raising domain level without thorough testing, potentially trapping deployment in incompatible state requiring extensive recovery efforts.

Test domain level raises in non-production environments mirroring production configuration. Validate all integrated applications and services function correctly at higher domain level. Document rollback plan acknowledging domain level cannot be lowered (rollback requires restoring from backup before raise). Implement maintenance window with adequate time for validation. Ensure recent tested backups exist before raising domain level in production.

Server Version Verification Gaps Enable Incompatible Topology

While domain level prevents adding replicas running incompatible versions after raise, verification of all servers before raising relies on manual checks. Automated version detection may miss servers temporarily offline or isolated by network issues. Raising domain level while incompatible servers exist causes replication failures and topology corruption.

Implement comprehensive server inventory verification before domain level raises. Use ipa server-find --all to identify all known servers and check versions. Verify network connectivity to all servers before raise: ping and replication status checks. Schedule domain level raises when all servers are confirmed online and healthy. Monitor replication after raise to quickly detect any issues with missed servers.

Domain Level Modification Without Authorization Workflow

The domainlevel-set command has immediate permanent effect without approval workflow or confirmation prompt. Accidental or unauthorized domain level raises cannot be undone. Insufficient access controls on domain level modification allow unauthorized administrators to make irreversible infrastructure changes.

Restrict domain level modification permissions to highly trusted senior administrators. Review permission grants: ipa permission-show 'System: Modify Domain Level'. Implement change management requiring approval before domain level modifications. Use scripting wrappers requiring confirmation and justification. Audit domain level modification commands in IPA logs. Consider custom RBAC limiting which administrators can modify domain level.

Replication Disruption During Domain Level Raise

Domain level raising requires updates to LDAP across all servers. Brief replication interruptions or delays may occur during the transition. If replication agreements are unhealthy before raise, domain level modification can fail or leave topology in inconsistent state. Concurrent user/host/service modifications during raise may conflict with domain level changes.

Verify replication is fully healthy before raising domain level: ipa-replica-manage list should show no errors. Schedule domain level raises during maintenance windows with minimal user activity. Implement change freeze preventing concurrent administrative operations during raise. Monitor replication status immediately after raise: ipa-replica-manage list and check for new errors. Have backups and recovery procedures ready in case of replication issues.

Feature Enablement Without Security Review

Raising domain level enables new features immediately across entire deployment. These new features may have security implications not reviewed by security team. Trust relationships, topology modifications, and other advanced features become available without explicit approval or security assessment. Administrators may begin using new features before security policies are established.

Conduct security review of features gated by domain level before raising. Document which features become available at higher levels. Establish usage policies for new features before domain level raise. Implement monitoring for use of newly enabled features. Train administrators on security implications of domain-level-gated features. Consider phased enablement where features are technically available but organizationally restricted until policies are ready.

Testing Inadequacy Risks Production Stability

Production domain level raises without adequate testing risk widespread service disruptions. Testing only on single-server lab environments may miss replication, performance, or integration issues that manifest in production multi-server topology. Insufficient testing time prevents discovery of subtle compatibility issues with integrated systems.

Maintain multi-server test environment mirroring production topology (minimum 2-3 servers with replication). Test domain level raises on realistic server versions and configurations. Allow adequate soak time after test raises to discover delayed issues: minimum 1 week recommended. Test all integrated services and applications after test domain level raise. Document test results and known issues before production raise. Include rollback exercises in testing (restore from backup).

Concurrent Administrative Operations During Domain Level Change

Executing domain level raises while other administrative operations are in progress (user creation, trust establishment, certificate operations) can cause conflicts or inconsistent states. The domain level modification touches core LDAP schema and configuration that other operations depend on. Race conditions may leave some changes incomplete or failed.

Implement change freeze during domain level modifications. Coordinate with all administrators to prevent concurrent changes. Use monitoring to verify no active administrative sessions during raise window. Schedule raises during low-activity periods (night/weekend). Document pre-raise checklist including verification no administrators logged in. Use IPA session monitoring: ipa session-find before raise.

Minimum Domain Level Enforcement Blocks Emergency Replica Addition

After raising domain level, adding emergency replacement replicas requires servers running minimum IPA version. In disaster recovery scenarios where only older IPA installation media is available, cannot add new replicas until installation media is updated. This can extend recovery time objectives when rapid replica replacement is needed.

Maintain updated IPA installation media matching current production version. Test replica installation procedures regularly using current media. Document minimum version requirements for current domain level in disaster recovery plans. Consider maintaining pre-built replica VMs or templates at current version. If domain level raised, update disaster recovery procedures and media immediately. Test replica recovery scenarios after domain level changes.

LDAP Schema Changes Without Client Validation

Domain level raises may modify LDAP schema available to clients. Applications or scripts using LDAP directly may depend on schema characteristics that change at higher domain levels. Schema incompatibilities may cause application failures not detected during server-focused testing. Client-side schema caching may cause delayed failures after domain level raise.

Inventory applications accessing IPA LDAP directly and test against higher domain level. Review schema changes introduced at target domain level. Test LDAP client applications in non-production environment after domain level raise. Clear client-side LDAP schema caches after production raise: restart applications and clear SSSD caches. Monitor application logs for LDAP errors after domain level changes. Implement gradual traffic migration if client compatibility issues are discovered.

Documentation Lag on Domain Level Feature Matrix

Official documentation may not clearly specify which features require which domain levels. Administrators may attempt to use features unavailable at current domain level, causing confusion. Incomplete feature matrix makes planning difficult: unclear whether raising domain level will enable desired functionality. Documentation for new features may not mention domain level prerequisites.

Consult multiple documentation sources when planning domain level raises: Red Hat documentation, community wiki, release notes. Test desired features in lab before raising production domain level. Use ipa server-find --all to identify feature availability on current servers. Join IPA community channels to clarify domain level requirements for specific features. Document internal feature-to-domain-level mapping based on testing.

Hidden Dependencies Between Domain Level and External Integrations

Active Directory trusts, cloud integrations, and third-party IDM products may have dependencies on specific domain levels. Vendor documentation may not specify domain level requirements. Raising domain level might break integrations or prevent use of integration features. External systems may cache IPA capabilities based on initial domain level.

Test all external integrations after domain level changes in non-production environment. Review vendor documentation for any domain level requirements or recommendations. Contact vendor support before production domain level raises in integrated environments. Monitor integration health after domain level changes: trust status, synchronization operations, authentication flows. Document domain level dependencies for each external integration.

Audit Trail Gaps for Domain Level Modifications

Domain level changes are recorded in LDAP changelog but may not integrate with enterprise SIEM or audit systems. Insufficient audit visibility makes compliance verification difficult. Unauthorized domain level changes may go undetected without active monitoring. Historical domain level state may not be preserved for forensic analysis.

Implement IPA audit log forwarding to SIEM: monitor /var/log/httpd/error_log for domain level changes. Configure alerts for domainlevel-set command execution. Maintain external documentation of domain level change history with dates and authorizations. Regularly export domain level state: ipa domainlevel-get > archive/$(date +%Y%m%d).txt. Review domain level in compliance audits and document business justification. Include domain level in backup documentation for forensic preservation.

Performance Impact of Topology Management Features

Raising domain level to 1 enables topology management which changes how replication is configured. Topology segments may create different replication paths than manual agreements, potentially affecting replication performance. Automatic topology segment creation might establish inefficient replication patterns. Increased metadata for topology management consumes additional LDAP resources.

Monitor replication performance after domain level raise: replication lag, entry update latency. Review topology segments created automatically and verify efficiency: ipa topologysegment-find domain. Optimize topology if needed by adding or removing segments for performance. Test replication load in non-production before production raise. Establish performance baselines before domain level change for comparison. Allocate additional monitoring during post-raise stabilization period.

Troubleshooting

Domain Level Raise Fails with Version Incompatibility Error

Symptom: Executing ipa domainlevel-set 1 fails with error message indicating one or more servers do not support the requested domain level.

Diagnosis: Check all server versions: ipa server-find --all | grep -i version. Identify which servers show “Max domain level” lower than target level. Verify servers are running minimum required IPA version for target level (level 1 requires FreeIPA 4.3+). Check for servers offline or unreachable that might not appear in server list.

Resolution: Upgrade all servers to minimum required version before raising domain level. For level 1, ensure all servers running FreeIPA 4.3 or newer: dnf update ipa-server on each server. Verify upgrades completed: ipa server-show servername.example.com --all | grep version. Restart IPA services after upgrades: ipactl restart. Once all servers upgraded, retry domain level raise: ipa domainlevel-set 1. If offline servers exist, bring them online or remove from topology before raising level.

Cannot Query Domain Level Due to Permission Error

Symptom: Running ipa domainlevel-get fails with “Insufficient access” or permission denied error.

Diagnosis: Verify user permissions: ipa user-show $(whoami) --all and check group memberships. Check if user has read access to domain level entry. Verify Kerberos authentication is valid: klist to check ticket. Test with admin account to isolate permission vs system issue.

Resolution: Ensure user is authenticated: kinit username if no valid ticket. For read-only access to domain level, user should be able to query as authenticated user. If permission denied, check if custom ACLs have been applied restricting access. Use admin account for troubleshooting: kinit admin && ipa domainlevel-get. Review permission settings: ipa permission-show 'System: Read Domain Level'. If custom permissions are blocking access, review and adjust ACI as needed.

Domain Level Raise Appears to Succeed But Level Unchanged

Symptom: Executing ipa domainlevel-set 1 returns success message but subsequent ipa domainlevel-get still shows previous level.

Diagnosis: Check for replication delays: domain level change may not have propagated yet. Verify command actually executed successfully without errors. Check IPA logs for any failure messages: /var/log/httpd/error_log. Test domain level query on different IPA server to rule out local issue. Review LDAP entry directly: ldapsearch -Y GSSAPI -b "cn=Domain Level,cn=ipa,cn=etc,dc=example,dc=com".

Resolution: Wait for replication to complete: typically 30-60 seconds. Force replication if needed: ipa-replica-manage force-sync --from=master.example.com. Verify replication is healthy: ipa-replica-manage list should show no errors. Restart IPA services if level still not updating: ipactl restart. Check for LDAP replication conflicts: ldapsearch -Y GSSAPI -b "dc=example,dc=com" "(nsds5ReplConflict=*)". If conflicts exist, resolve them before retrying domain level set.

Topology Commands Not Available After Raising Domain Level to 1

Symptom: After successfully raising domain level to 1, topology management commands like ipa topologysegment-find fail with “command not found” or feature unavailable errors.

Diagnosis: Verify domain level was actually raised: ipa domainlevel-get should show 1. Check IPA server version: ipa --version to confirm running 4.3+. Verify server supports topology plugin. Review if command is being run on correct server (not an un-upgraded client). Check for Python module issues: topology commands require specific IPA components.

Resolution: Restart IPA services to reload configuration: ipactl restart. Verify IPA server package version: rpm -q ipa-server should show 4.3 or newer. If server version is too old, upgrade: dnf update ipa-server. For clients, ensure using ipa command against server, not locally. Clear command cache: hash -r in bash. Test topology commands: ipa topologysuffix-show domain. If still failing, check for plugin installation: ipa-server-upgrade to ensure all components updated.

Domain Level Set Command Hangs or Times Out

Symptom: Executing ipa domainlevel-set 1 does not return, appears to hang indefinitely or times out after several minutes.

Diagnosis: Check network connectivity to all IPA servers: ping and verify reachability. Review replication status: hanging may indicate waiting for replication confirmation from offline server. Check system load and resource availability: high CPU or disk I/O may slow operation. Review IPA logs in real-time: tail -f /var/log/httpd/error_log for clues. Check for locked LDAP operations: ldapsearch -Y GSSAPI -b "cn=config" "(nsTaskStatus=*)".

Resolution: Ensure all IPA servers are online and responding: ipa server-find should list all servers as healthy. Fix any replication issues before retrying domain level set: ipa-replica-manage list and resolve errors. Increase command timeout if operation is legitimately slow: export IPA_TIMEOUT=600 && ipa domainlevel-set 1. Check for LDAP database locks or hung operations: restart Directory Server if needed: systemctl restart dirsrv@REALM.service. If specific server causing timeout, investigate that server’s logs: /var/log/dirsrv/slapd-REALM/errors.

Replication Broken After Domain Level Raise

Symptom: After raising domain level, replication between servers fails or shows errors in ipa-replica-manage list.

Diagnosis: Check specific replication errors in output: ipa-replica-manage list --verbose. Review Directory Server error logs on all servers: /var/log/dirsrv/slapd-REALM/errors. Test replication in both directions between affected servers. Verify network connectivity and firewall rules. Check for version mismatches that might have been missed before raise.

Resolution: Verify all servers are actually running compatible versions: ipa server-find --all. Check for servers that were offline during domain level raise and came back online with incompatible version. Re-initialize replication from healthy server: ipa-replica-manage re-initialize --from=healthy-server.example.com. Verify time synchronization: chronyc sources on all servers (time skew causes replication issues). Check LDAP change logs for corruption: may need to clear and rebuild. Restart Directory Server on affected servers: systemctl restart dirsrv@REALM.service.

Cannot Add New Replica After Domain Level Raise

Symptom: Attempting to install new replica after domain level raise fails with version compatibility or domain level errors.

Diagnosis: Verify new replica server IPA version: rpm -q ipa-server should meet minimum for current domain level. Check domain level requirement: level 1 requires FreeIPA 4.3+. Review replica installation error messages for specific version requirements. Confirm domain level on master: ipa domainlevel-get.

Resolution: Ensure new replica runs minimum IPA version for current domain level. For domain level 1, upgrade replica OS and packages to provide FreeIPA 4.3 or newer: dnf update ipa-*. Cannot install older replica version after domain level raise; must match or exceed domain level requirements. If unable to upgrade replica server, either downgrade domain level expectations (not possible after raise) or use newer OS for replica. Document minimum server requirements in replica installation procedures.

Previous Features No Longer Working After Domain Level Raise

Symptom: After raising domain level, certain commands or features that previously worked now fail or behave differently.

Diagnosis: Identify which specific features changed behavior. Review domain level release notes for deprecated or changed functionality. Check if features moved from legacy to new implementation (e.g., manual replication to topology). Review command syntax for any changes in newer IPA versions. Test same operations on server at same version but lower domain level (if test environment available).

Resolution: Update procedures to use new feature implementations at higher domain level. For replication, migrate from ipa-replica-manage to ipa topologysegment-* commands. Review IPA upgrade documentation for compatibility notes. Update scripts and automation using deprecated commands. Retrain administrators on new feature implementations. If critical feature broken, review if bug or expected change: consult release notes and file bug if needed. Cannot rollback domain level, must adapt to new functionality.

Server Maximum Domain Level Lower Than Current Domain Level

Symptom: Running ipa server-find --all shows a server with “Max domain level” lower than current domain level retrieved by ipa domainlevel-get.

Diagnosis: Identify how server with lower max level exists in topology at higher domain level: might indicate server was upgraded but not restarted, or metadata stale. Check actual IPA version on affected server: rpm -q ipa-server logged in to that server. Verify server is actually functioning and replicating. Review when server was last upgraded versus when domain level was raised.

Resolution: If server was recently upgraded, restart IPA services: ipactl restart to refresh version metadata. Run server upgrade procedure: ipa-server-upgrade to update all components. Verify version after restart: ipa server-show servername.example.com --all. If server truly cannot support current domain level, indicates improper domain level raise occurred with incompatible server present. May need to remove and re-add server if metadata cannot be corrected. Document incident and improve pre-raise verification procedures.

Domain Level Information Not Replicating to All Servers

Symptom: Different IPA servers report different domain levels when queried with ipa domainlevel-get.

Diagnosis: Check replication status between servers showing different levels: ipa-replica-manage list. Review if servers are isolated by network issues. Verify which server was used for domain level set command. Check LDAP changelog for replication of domain level entry. Review time of last replication between affected servers.

Resolution: Force replication between servers: ipa-replica-manage force-sync --from=source-server --to=target-server. Verify domain level entry exists on all servers: ldapsearch -Y GSSAPI -b "cn=Domain Level,cn=ipa,cn=etc,dc=example,dc=com" on each server. Check for replication conflicts: ldapsearch -Y GSSAPI -b "dc=example,dc=com" "(nsds5ReplConflict=*)" and resolve. Restart replication if needed: ipa-replica-manage disconnect server then ipa-replica-manage connect server. Monitor replication until all servers synchronized. If persistent, may need to re-initialize affected replica.

Command Line Help Does Not List Available Domain Levels

Symptom: Running ipa domainlevel-set --help or reviewing IPA documentation does not clearly indicate which domain level values are valid for current deployment.

Diagnosis: Review IPA server version to understand supported domain levels. Check release notes for version-specific domain level information. Attempt to set various levels and observe error messages indicating valid range. Query server capabilities: ipa server-find --all and review max/min domain level fields.

Resolution: For FreeIPA 4.3+, valid domain levels are 0 and 1. Future versions may support higher levels. Review output of ipa server-find --all for each server’s supported range. Consult Red Hat/FreeIPA documentation for specific version’s domain level support. Test in non-production environment to determine valid levels. Document supported domain levels for current IPA version in operational procedures. When in doubt, query current level and increment by 1 as target.

Backup Restoration Resets Domain Level

Symptom: After restoring IPA from backup, domain level appears lower than before backup, causing feature availability issues.

Diagnosis: Verify backup timestamp predates domain level raise. Check domain level in backup: ipa domainlevel-get immediately after restore. Review backup procedures to confirm domain level configuration is captured. Determine if backup was from before domain level modification.

Resolution: If backup predates domain level raise, re-raise domain level after restore: ipa domainlevel-set 1. Ensure all servers support target level before re-raising. Update backup procedures to include domain level in metadata: ipa domainlevel-get > backup-metadata.txt. For disaster recovery scenarios, document current domain level in runbooks. Test backup/restore procedures to verify domain level preservation. Consider scheduled backups after configuration changes to capture latest state. If domain level cannot be re-raised due to version issues, may need to restore servers to compatible state.

Attempting to Lower Domain Level After Accidental Raise

Symptom: Domain level was raised accidentally or prematurely and administrator wants to lower it back to previous level.

Diagnosis: Understand that domain level cannot be lowered through IPA commands. Check if domain level raise was very recent and backup exists from before raise. Review impact of current domain level on operations. Assess if current level causes actual issues or just differs from intended state.

Resolution: Accept that domain level cannot be lowered once raised. If absolutely critical to revert, only option is complete restore from backup taken before domain level raise: full LDAP restore procedure. This is disruptive and causes loss of all changes since backup. Evaluate if living with current domain level is acceptable versus restore disruption. If restore required, follow disaster recovery procedures: restore all servers from backup point before domain level raise. For future, implement stronger controls on domain level modifications: approval workflows, testing requirements, change management. Document incident and improve procedures to prevent accidental raises.