Miscellaneous

Overview

The miscellaneous commands category contains utility functions for inspecting IPA’s internal state, configuration, and plugin architecture. These commands are primarily used for troubleshooting, development, and understanding the IPA server’s operational environment.

env - Environment Variables

The env command displays IPA’s internal environment variables and configuration settings. These variables define how the IPA framework operates, including API version, plugin paths, server configuration, and authentication settings. The command provides visibility into the runtime configuration of both the IPA client and server.

Key uses:

Troubleshooting configuration issues
Verifying API compatibility between client and server
Identifying active server connections
Inspecting internal IPA settings for development

Environment variables include:

server: Active IPA server hostname
xmlrpc_uri: API endpoint URL
api_version: IPA API version
context: Execution context (cli, server, installer, etc.)
domain: IPA domain name
realm: Kerberos realm
basedn: LDAP base DN
plugins: Loaded plugin names

The env command can run locally (client-side, showing client configuration) or be forwarded to the server (--server) to inspect server-side environment.

plugins - Plugin Information

The plugins command enumerates all loaded IPA plugins, showing the complete plugin architecture. IPA’s functionality is implemented through a modular plugin system, and this command reveals which plugins are active.

Key uses:

Verifying custom plugins are loaded
Diagnosing feature availability issues
Development and debugging of IPA extensions
Understanding IPA’s internal architecture

Plugin types:

Command plugins: Implement IPA commands (user-add, group-mod, etc.)
Object plugins: Define IPA object types (user, group, host, etc.)
Method plugins: Implement RPC methods
Backend plugins: Database backends (LDAP, etc.)

Like env, the plugins command can run locally or be forwarded to the server to inspect server-side plugins.

Common Use Cases

Debugging API version mismatches: When client and server have different API versions, operations may fail. ipa env api_version shows both client and server versions.

Verifying server connectivity: ipa env server confirms which IPA server the client is communicating with, useful for multi-server deployments.

Custom plugin verification: After installing custom plugins, ipa plugins verifies the plugin loaded successfully.

Configuration auditing: ipa env output documents IPA’s configuration state for compliance or troubleshooting records.

Examples

Show All Environment Variables

# Display complete IPA environment
ipa env
# Output shows 50+ environment variables:
# api_version: 2.251
# basedir: /usr/share/ipa
# confdir: /etc/ipa
# context: cli
# domain: example.com
# enable_ra: True
# in_server: False
# in_tree: False
# ldap_uri: ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-COM.socket
# mode: production
# prompt_all: False
# realm: EXAMPLE.COM
# server: ipa.example.com
# startup_traceback: False
# verbose: 0
# xmlrpc_uri: https://ipa.example.com/ipa/xml
# ... (50+ more variables)

Show Specific Environment Variables

# Display only server and API version
ipa env server api_version
# Output:
# server: ipa.example.com
# api_version: 2.251

# Display realm and domain
ipa env realm domain
# Output:
# realm: EXAMPLE.COM
# domain: example.com

Compare Client and Server Environment

# Show client-side environment (default)
ipa env api_version context
# Output:
# api_version: 2.251
# context: cli

# Show server-side environment
ipa env --server api_version context
# Output:
# api_version: 2.251
# context: server

# Different contexts show you're comparing client vs server

Verify Server Connectivity

# Check which server the client is using
ipa env server xmlrpc_uri
# Output:
# server: ipa01.example.com
# xmlrpc_uri: https://ipa01.example.com/ipa/xml

# In multi-server deployment, confirms active server

List All Loaded Plugins

# Show all plugins
ipa plugins
# Output shows all loaded plugins (500+ plugins):
# automember
# baseldap
# batch
# ca
# caacl
# cert
# certprofile
# config
# delegation
# dns
# dnsrecord
# dnszone
# group
# hbacrule
# hbacsvc
# host
# ... (500+ plugins)

Verify Custom Plugin Loaded

# Check if specific plugin is loaded
ipa plugins | grep my_custom_plugin
# If output shows plugin name, it's loaded

# Alternative: Check all plugins containing 'custom'
ipa plugins | grep -i custom

Server-Side Plugin Inspection

# Show plugins loaded on server (not client)
ipa plugins --server
# Output shows server-side plugins (may differ from client)

# Compare client and server plugins
ipa plugins > client-plugins.txt
ipa plugins --server > server-plugins.txt
diff client-plugins.txt server-plugins.txt

Debugging API Version Mismatch

# Client API version
ipa env api_version
# api_version: 2.240

# Server API version
ipa env --server api_version
# api_version: 2.251

# Version mismatch detected: client 2.240, server 2.251
# Update client to match server version

Inspecting LDAP Connection URI

# Check LDAP connection method
ipa env ldap_uri
# ldap_uri: ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-COM.socket

# LDAPI (LDAP over IPC socket) indicates local server access
# LDAP:// would indicate network connection

Verifying Certificate Authority Status

# Check if CA is enabled
ipa env enable_ra
# enable_ra: True (CA is enabled)

# If False, IPA is running without integrated CA

Development: Checking IPA Mode

# Check if running in development mode
ipa env mode in_tree startup_traceback
# Output:
# mode: production
# in_tree: False
# startup_traceback: False

# Development installations show:
# mode: development
# in_tree: True
# startup_traceback: True

Use Cases

1. Diagnosing Client-Server API Version Mismatch

User reports “ipa” commands fail with “API version mismatch” errors after server upgrade.

# Check client API version
ipa env api_version
# api_version: 2.230

# Check server API version
ipa env --server api_version
# api_version: 2.251

# Mismatch detected: client too old
# Client running IPA 4.8, server running IPA 4.11

# Update IPA client packages
dnf update ipa-client

# Verify versions now match
ipa env api_version
# api_version: 2.251

ipa env --server api_version
# api_version: 2.251

# Commands now work

Result: API version mismatch identified and resolved by updating client packages to match server version.

2. Verifying Custom Plugin Installation

Administrator installed custom IPA plugin to add organization-specific attributes. Need to verify plugin loaded correctly.

# Check if custom plugin appears in plugin list
ipa plugins | grep orgextension
# (No output - plugin not loaded)

# Check server-side plugins
ipa plugins --server | grep orgextension
# (No output - plugin not loaded on server either)

# Check plugin file exists
ls -l /usr/share/ipa/plugins/orgextension.py
# File exists

# Check for Python syntax errors
python3 -m py_compile /usr/share/ipa/plugins/orgextension.py
# SyntaxError: invalid syntax (line 42)

# Fix syntax error in plugin code
vim /usr/share/ipa/plugins/orgextension.py
# Correct syntax issue

# Restart IPA services to reload plugins
ipactl restart

# Verify plugin now loaded
ipa plugins | grep orgextension
# orgextension

# Plugin successfully loaded

Result: Custom plugin was not loading due to Python syntax error. Error identified, corrected, and plugin verified loaded after service restart.

3. Identifying Active IPA Server in Multi-Server Deployment

In deployment with 5 IPA replicas, administrator needs to confirm which server the client is currently using.

# Check active server
ipa env server
# server: ipa03.example.com

# Verify connection endpoint
ipa env xmlrpc_uri
# xmlrpc_uri: https://ipa03.example.com/ipa/xml

# Client is using ipa03, but we want it to prefer local ipa01

# Check client configuration
cat /etc/ipa/default.conf | grep server
# (No explicit server configured - using DNS discovery)

# Check DNS SRV records client is using
dig +short SRV _kerberos._udp.example.com
# 0 100 88 ipa01.example.com.
# 0 100 88 ipa03.example.com.
# 50 100 88 ipa02.example.com.

# Both ipa01 and ipa03 have same priority
# Client may have chosen ipa03 randomly

# Force client to use ipa01
echo "server = ipa01.example.com" >> /etc/ipa/default.conf

# Verify change
ipa env server
# server: ipa01.example.com

# Client now explicitly uses ipa01

Result: Identified client was using ipa03.example.com via DNS discovery. Configured client to explicitly use local ipa01.example.com for improved latency.

4. Troubleshooting Missing LDAP Connection

User cannot connect to IPA LDAP server. Need to verify LDAP connection configuration.

# Check LDAP URI configuration
ipa env ldap_uri
# ldap_uri: ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-COM.socket

# URI shows LDAPI (local Unix socket connection)
# This only works on IPA server itself

# Check if client is mistakenly configured for local LDAP
hostname
# client01.example.com (not an IPA server)

# Client shouldn't use LDAPI, should use LDAP://
# Check IPA client enrollment status
ipa-client-install --unattended --force-join \
  --server=ipa.example.com \
  --domain=example.com

# After re-enrollment, check LDAP URI
ipa env ldap_uri
# ldap_uri: ldap://ipa.example.com

# Now correctly configured for network LDAP

Result: Client was misconfigured with LDAPI socket connection (only for IPA servers). Re-enrollment fixed LDAP URI to use network connection.

5. Verifying IPA Installation Mode for Development

Developer working on IPA plugin needs to verify IPA is in development mode with detailed error reporting.

# Check IPA mode and debugging settings
ipa env mode in_tree startup_traceback verbose debug
# Output:
# mode: production
# in_tree: False
# startup_traceback: False
# verbose: 0
# debug: False

# IPA is in production mode, not suitable for development

# Enable debug mode
echo "debug = True" >> /etc/ipa/default.conf
echo "verbose = 2" >> /etc/ipa/default.conf

# Check settings again
ipa env debug verbose startup_traceback
# Output:
# debug: True
# verbose: 2
# startup_traceback: False

# Debug and verbose logging now enabled
# startup_traceback still False (requires server config change)

# Enable server-side debug logging
echo "debug = True" >> /etc/ipa/server.conf
systemctl restart httpd

# Now full debugging enabled for plugin development

Result: IPA installation verified as production mode. Debug and verbose logging enabled in client and server configuration for plugin development.

6. Checking Certificate Authority Configuration

Administrator needs to verify if IPA is running with integrated CA or external CA.

# Check CA/RA status
ipa env enable_ra ra_plugin
# Output:
# enable_ra: True
# ra_plugin: dogtag

# enable_ra: True means CA is enabled
# ra_plugin: dogtag means using Dogtag PKI

# Verify CA server
ipa env ca_host
# ca_host: ipa.example.com

# Check if current server is CA server
ipa env host ca_host
# Output:
# host: ipa.example.com
# ca_host: ipa.example.com

# Current server IS the CA server

# List all CA servers
ipa server-role-find --role="CA server"
# Shows all servers with CA role

Result: Confirmed IPA has integrated CA (Dogtag) enabled and current server hosts CA role.

7. Inspecting IPA Context for Script Automation

Writing automation script that needs to behave differently when run on IPA server vs client.

# Check execution context
ipa env context in_server
# Output:
# context: cli
# in_server: False

# Running on IPA client (cli context, not in_server)

# On IPA server, same command shows:
# context: cli
# in_server: True

# Script can detect context:
if ipa env in_server | grep -q "True"; then
  echo "Running on IPA server"
  # Server-specific logic
else
  echo "Running on IPA client"
  # Client-specific logic
fi

Result: Script uses ipa env in_server to detect execution environment and adapt behavior for server vs client scenarios.

8. Documenting IPA Configuration for Audit

Security audit requires documentation of current IPA configuration state.

# Generate complete environment documentation
ipa env > /tmp/ipa-config-audit-$(date +%Y%m%d).txt

# Generate plugin inventory
ipa plugins > /tmp/ipa-plugins-audit-$(date +%Y%m%d).txt

# Generate server-side environment
ipa env --server > /tmp/ipa-server-config-audit-$(date +%Y%m%d).txt

# Create comprehensive audit report
cat > /tmp/ipa-audit-report-$(date +%Y%m%d).md <<EOF
# IPA Configuration Audit - $(date)

## Server Information
$(ipa env server realm domain basedn)

## API Version
$(ipa env api_version)

## Certificate Authority
$(ipa env enable_ra ra_plugin ca_host)

## LDAP Configuration
$(ipa env ldap_uri)

## Plugins Loaded
$(ipa plugins | wc -l) plugins loaded

## Full Environment
See attached: ipa-config-audit-$(date +%Y%m%d).txt
EOF

# Audit documentation generated
cat /tmp/ipa-audit-report-$(date +%Y%m%d).md

Result: Complete IPA configuration documented for security audit including environment variables, plugin inventory, and CA configuration.

9. Comparing Development and Production Environments

Developer needs to verify development IPA environment matches production configuration.

# On production server
ipa env > /tmp/prod-env.txt
ipa plugins > /tmp/prod-plugins.txt

# Copy to development server
scp /tmp/prod-env.txt dev-ipa:/tmp/
scp /tmp/prod-plugins.txt dev-ipa:/tmp/

# On development server
ipa env > /tmp/dev-env.txt
ipa plugins > /tmp/dev-plugins.txt

# Compare environments
diff /tmp/prod-env.txt /tmp/dev-env.txt
# Output shows differences:
# < api_version: 2.251
# > api_version: 2.240
# < server: ipa-prod.example.com
# > server: ipa-dev.example.com

# Compare plugins
diff /tmp/prod-plugins.txt /tmp/dev-plugins.txt
# Output shows:
# < custom_prod_plugin
# (Custom plugin exists in prod but not dev)

# Identify missing plugin
# Install missing plugin on dev
# Update dev IPA version to match prod

Result: Configuration drift identified between production and development. Development environment updated to match production API version and plugin inventory.

10. Identifying IPA Domain and Realm Configuration

New administrator needs to quickly identify IPA’s domain, realm, and base DN for documentation.

# Get domain and realm information
ipa env domain realm basedn
# Output:
# domain: example.com
# realm: EXAMPLE.COM
# basedn: dc=example,dc=com

# Verify server hostname
ipa env server host
# Output:
# server: ipa.example.com
# host: ipa.example.com

# Generate configuration summary
cat > /tmp/ipa-config-summary.txt <<EOF
IPA Configuration Summary
=========================

Domain: $(ipa env domain | awk '{print $2}')
Realm: $(ipa env realm | awk '{print $2}')
Base DN: $(ipa env basedn | awk '{print $2}')
Server: $(ipa env server | awk '{print $2}')
API Version: $(ipa env api_version | awk '{print $2}')

CA Enabled: $(ipa env enable_ra | awk '{print $2}')
CA Plugin: $(ipa env ra_plugin | awk '{print $2}')

Context: $(ipa env context | awk '{print $2}')
Mode: $(ipa env mode | awk '{print $2}')
EOF

cat /tmp/ipa-config-summary.txt

Result: Quickly extracted key IPA configuration parameters for documentation and reference.

Security Considerations

Information Disclosure via Environment Variables

The ipa env command reveals internal IPA configuration details including server hostnames, domain structure, LDAP URIs, and plugin architecture. While these variables are generally non-sensitive, they provide reconnaissance information useful for attackers. The env command does not require administrative privileges—any authenticated user can run it and discover internal IPA infrastructure details. In high-security environments, consider monitoring ipa env usage for reconnaissance attempts (unusual users or patterns). The information disclosed is necessary for client operation and cannot be restricted without breaking functionality.

Plugin Enumeration for Vulnerability Discovery

The ipa plugins command enumerates all loaded plugins, revealing which features are active and potentially which plugins are custom or third-party. Attackers can use this information to identify attack surface (which features to target) and discover vulnerable plugins (e.g., custom plugins with security flaws). If custom plugins are loaded, ensure they follow secure coding practices and are regularly audited. Monitor access logs for ipa plugins commands from unexpected sources, which may indicate reconnaissance activity. Plugin enumeration is necessary for administration and cannot be restricted.

API Version Exposure

The api_version environment variable reveals the exact IPA version in use. Attackers can use this to identify known vulnerabilities in specific IPA versions and craft targeted exploits. While security through obscurity is not a defense, version disclosure lowers the barrier for automated exploitation. Ensure IPA is kept up-to-date with security patches. Monitor for ipa env api_version queries from unusual sources. Version information is publicly discoverable through other means (HTTP headers, error messages), so this exposure is not unique to the env command.

LDAP URI Disclosure

The ldap_uri variable reveals how IPA connects to its LDAP backend, potentially including socket paths (LDAPI) or network addresses (LDAP://). For LDAPI configurations, socket paths may reveal directory structure. For LDAP:// configurations, network topology is disclosed. This information is generally low-risk but contributes to reconnaissance. Ensure LDAP connections use authenticated binds and TLS (LDAPS) where applicable. LDAPI socket permissions prevent unauthorized access even if path is known.

Server Hostname Disclosure

The server and xmlrpc_uri variables reveal the active IPA server hostname and API endpoint. In multi-server deployments, this discloses topology and server naming schemes. Attackers can use this to map IPA infrastructure and identify high-value targets (e.g., primary server vs replicas). Use non-descriptive hostnames (ipa01, ipa02) rather than descriptive names (ipa-primary, ipa-backup) to minimize information leakage. Monitor for unusual patterns in server discovery attempts.

Execution Context Leakage

The context and in_server variables reveal whether commands are executing on an IPA server or client, and in what context (cli, server, installer, etc.). This information helps attackers distinguish between high-value targets (IPA servers) and clients. While this information is necessary for troubleshooting, be aware it contributes to infrastructure mapping. Restrict SSH access to IPA servers to prevent attackers from using ipa env to identify server systems.

CA Configuration Disclosure

The enable_ra, ra_plugin, and ca_host variables disclose whether IPA has an integrated CA and which server hosts it. CA servers are high-value targets as they control certificate issuance for the entire domain. Ensure CA servers have additional hardening (restricted access, enhanced monitoring, security patches). Monitor for queries to CA-related environment variables from unexpected sources. CA configuration is also discoverable through DNS SRV records and certificate issuance behaviors.

Debug Mode Detection

The debug, verbose, and startup_traceback variables reveal whether debug logging is enabled. Debug mode may leak sensitive information in logs (passwords, internal state, detailed error messages). Attackers can use this to determine if verbose logging will reveal exploitable information. Ensure debug mode is disabled in production environments: ipa env debug should return False. If debug logging is temporarily enabled for troubleshooting, disable immediately after and rotate/review logs for sensitive data exposure.

Custom Plugin Discovery

Custom plugins visible via ipa plugins may have security vulnerabilities not present in official IPA plugins (lack of security review, insecure coding practices, outdated dependencies). Attackers can identify custom plugins and focus exploitation efforts on these potentially weaker targets. Ensure custom plugins undergo security review, follow IPA’s plugin development best practices, and are regularly updated. Monitor for unusual access patterns targeting custom plugin functionality.

Base DN and Domain Disclosure

The basedn, domain, and realm variables disclose IPA’s LDAP structure and Kerberos realm configuration. While necessary for client operation, this information aids LDAP injection attacks, Kerberos attacks (brute-force, golden ticket), and social engineering (understanding organizational structure). This information is also discoverable through DNS (TXT records for realm) and Kerberos error messages, so exposure via ipa env is not unique. Ensure strong password policies and MFA to mitigate Kerberos attacks regardless of realm disclosure.

Environment Variable Command Injection

If ipa env output is programmatically parsed and used in shell scripts without proper escaping, environment variables containing special characters could enable command injection. For example, if a malicious plugin modifies an environment variable to include shell metacharacters and a script executes eval $(ipa env malicious_var), arbitrary command execution may occur. Always sanitize and validate ipa env output before using in scripts. Use safe parsing (read into variables, don’t eval raw output). This is a script-level vulnerability, not an IPA vulnerability, but misconfiguration can enable exploitation.

No Access Control for env/plugins Commands

Both env and plugins commands require only basic authentication (valid Kerberos ticket or LDAP bind). Any authenticated user, including low-privilege accounts, can enumerate environment and plugins. This is intentional (clients need environment information to function), but creates persistent reconnaissance risk. Monitor access logs for excessive ipa env or ipa plugins queries (potential reconnaissance). Implement account lifecycle management to ensure unused/compromised accounts are promptly disabled, limiting persistent access for reconnaissance.

Troubleshooting

ipa env Returns Different Results Than Expected

Symptoms: ipa env command output doesn’t match expected configuration. Variables show unexpected values.

Diagnosis:

# Check if running locally vs server
ipa env context in_server
# context: cli
# in_server: False (running locally)

# Try server-side environment
ipa env --server context in_server
# context: server
# in_server: True (server-side)

# Client and server environments differ

Resolution: By default, ipa env shows client-side environment. Use --server flag to inspect server-side environment. Client environment is derived from /etc/ipa/default.conf and client configuration, while server environment reflects actual server state. Differences are expected and normal.

ipa env server Shows Unexpected Server

Symptoms: ipa env server shows different server than expected in multi-server deployment.

Diagnosis:

# Check configured server
ipa env server xmlrpc_uri
# server: ipa03.example.com
# xmlrpc_uri: https://ipa03.example.com/ipa/xml

# Check if server explicitly configured
cat /etc/ipa/default.conf | grep server
# (No output - using DNS discovery)

# Check DNS SRV records
dig +short SRV _kerberos._tcp.example.com
# Multiple servers with same priority

Resolution: If no explicit server is configured in /etc/ipa/default.conf, client uses DNS SRV discovery and may select any server with highest priority. To force specific server, add server = ipa01.example.com to /etc/ipa/default.conf. Alternatively, adjust DNS SRV record priorities to prefer specific servers.

ipa plugins Shows Fewer Plugins Than Expected

Symptoms: ipa plugins returns significantly fewer plugins than expected (e.g., 50 plugins instead of 500+).

Diagnosis:

# Check plugin count
ipa plugins | wc -l
# 52

# Expected ~500 plugins in modern IPA

# Check if running locally vs server
ipa env in_server
# in_server: False (client-side)

# Check server-side plugins
ipa plugins --server | wc -l
# 487

Resolution: Local ipa plugins shows client-side plugins (minimal set). Server-side has full plugin set. Use --server flag to inspect server plugins: ipa plugins --server. Client-side plugin count is expected to be much lower than server.

Custom Plugin Not Appearing in ipa plugins

Symptoms: After installing custom plugin, it doesn’t appear in ipa plugins output.

Diagnosis:

# Check plugin file exists
ls -l /usr/share/ipa/plugins/mycustomplugin.py
# File exists

# Check for Python syntax errors
python3 -m py_compile /usr/share/ipa/plugins/mycustomplugin.py
# SyntaxError: invalid syntax

# Check IPA logs for plugin load errors
journalctl -u httpd | grep -i plugin
# Error loading plugin: mycustomplugin

Resolution: Custom plugin may have Python syntax errors preventing loading. Compile plugin file to check syntax: python3 -m py_compile plugin.py. Fix syntax errors. Ensure plugin file is in correct location (/usr/share/ipa/plugins/ or /usr/lib/python3.X/site-packages/ipaserver/plugins/). After fixes, restart IPA: ipactl restart. Verify plugin loads: ipa plugins | grep mycustom.

API Version Mismatch Error

Symptoms: IPA commands fail with “API version mismatch” or “Forward to server failed” errors.

Diagnosis:

# Check client API version
ipa env api_version
# api_version: 2.230

# Check server API version
ipa env --server api_version
# api_version: 2.251

# Mismatch: client 2.230, server 2.251
# Client is outdated

Resolution: Update IPA client packages to match server version: dnf update ipa-client (RHEL/CentOS) or apt update && apt upgrade freeipa-client (Debian/Ubuntu). After update, verify versions match: ipa env api_version should match ipa env --server api_version. If server is outdated instead, update server: dnf update ipa-server && ipactl restart.

ipa env Shows in_server: True on Client

Symptoms: Client system shows in_server: True when it should not be an IPA server.

Diagnosis:

# Check in_server status
ipa env in_server
# in_server: True (unexpected on client)

# Check if IPA server software installed
rpm -qa | grep ipa-server
# ipa-server-4.9.8-1.el8.x86_64 (server packages present!)

# Check if IPA services running
ipactl status
# IPA services are running

Resolution: System has IPA server software installed and running, making it an actual server, not just a client. If this is unexpected, the system may have been mistakenly configured as a replica. To demote to client-only: uninstall IPA server (ipa-server-install --uninstall), then re-enroll as client (ipa-client-install). If system should be a server, this is correct behavior.

ipa env Returns “Connection refused”

Symptoms: ipa env command fails with “Cannot connect to server” or connection refused errors.

Diagnosis:

# Try local environment (doesn't require server)
ipa env

# If local works but --server fails:
ipa env --server
# Error: cannot connect to 'https://ipa.example.com/ipa/xml'

# Check if server is accessible
ping ipa.example.com

# Check if IPA web services are running
curl -I https://ipa.example.com/ipa/xml
# Connection refused

# Check on IPA server
ssh ipa.example.com "ipactl status"
# Directory Service: STOPPED
# ... other services stopped

Resolution: IPA server services are not running. On server, start services: ipactl start. If services fail to start, check logs: journalctl -u ipa. Common issues: certificate expiration, disk space, database corruption. Address underlying issue and restart services. After services running, retry ipa env --server.

ldap_uri Shows Wrong URI Type

Symptoms: ipa env ldap_uri shows ldapi:// (Unix socket) when network LDAP connection expected, or vice versa.

Diagnosis:

# Check LDAP URI
ipa env ldap_uri
# ldap_uri: ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-COM.socket

# LDAPI only works on IPA server itself
# Check if this is a server or client
ipa env in_server
# in_server: False (client - should use ldap://)

# Client misconfigured with server-style LDAPI

Resolution: IPA clients should use ldap:// or ldaps:// URIs, not ldapi:// (which is for local server access only). Re-enroll client: ipa-client-install --force-join --server=ipa.example.com. This regenerates correct client configuration with network LDAP URI. On servers, ldapi:// is correct and expected.

enable_ra Shows False When CA Expected

Symptoms: ipa env enable_ra returns False, but IPA should have integrated CA.

Diagnosis:

# Check CA status
ipa env enable_ra ra_plugin
# enable_ra: False
# ra_plugin: (not shown)

# Check if CA services are running
systemctl status pki-tomcatd@pki-tomcat
# Unit not found (CA not installed)

# Check IPA server role
ipa server-role-find --role="CA server"
# 0 CA servers found

Resolution: IPA installation does not have integrated CA. This may be intentional (IPA configured with external CA or self-signed certificates). If CA should be installed: install CA on IPA server: ipa-ca-install. If CA is on different replica, enable_ra will be False on non-CA replicas. Verify at least one server has CA role: ipa server-role-find --role="CA server".

Debugging: verbose Shows 0 When Debug Enabled

Symptoms: Enabled debug logging but ipa env verbose shows 0.

Diagnosis:

# Check verbose level
ipa env verbose debug
# verbose: 0
# debug: False

# Check client configuration file
cat /etc/ipa/default.conf | grep -E "debug|verbose"
# (No output - not configured)

# Configuration changes not applied

Resolution: Debug and verbose settings must be in /etc/ipa/default.conf for client-side, or /etc/ipa/server.conf for server-side. Add to config file: echo "debug = True" >> /etc/ipa/default.conf and echo "verbose = 2" >> /etc/ipa/default.conf. For server-side debugging, modify /etc/ipa/server.conf and restart httpd: systemctl restart httpd. Verify with ipa env debug verbose.

env Command Times Out

Symptoms: ipa env command hangs for long time then times out.

Diagnosis:

# Try without network (local only - no timeout)
timeout 5 ipa env
# Returns quickly with local environment

# Try server-side (may timeout)
timeout 30 ipa env --server
# Timeout after 30 seconds

# Check server connectivity
ping -c 3 ipa.example.com
# Packets received OK

# Check if API endpoint accessible
curl -I https://ipa.example.com/ipa/xml
# Connection timeout (no response)

# Firewall or network issue blocking HTTPS

Resolution: Network connectivity issue prevents reaching IPA server’s API endpoint (port 443). Check firewall rules on client and server. Verify IPA web services running: ipactl status. Check Apache logs on server for errors: journalctl -u httpd. Test port 443 connectivity: telnet ipa.example.com 443. If firewall blocking, open port 443 or adjust rules.

plugin List Missing Expected Plugins

Symptoms: Critical plugins missing from ipa plugins output. Expected features don’t work.

Diagnosis:

# Check if specific plugin loaded
ipa plugins | grep dns
# (No output - DNS plugin not loaded)

# DNS feature should be available
ipa dnszone-find
# ipa: ERROR: unknown command 'dnszone_find'

# Check if DNS was installed
rpm -qa | grep ipa-server-dns
# (No packages found)

Resolution: Plugin missing because corresponding feature not installed. For DNS: install DNS support: ipa-dns-install. For other missing plugins, verify feature packages are installed: rpm -qa | grep ipa-server. After installing feature, restart IPA: ipactl restart. Verify plugin now appears: ipa plugins | grep dns.

Client Shows Different domain Than Server

Symptoms: Client and server show different domain/realm values in ipa env.

Diagnosis:

# Client domain
ipa env domain realm
# domain: example.com
# realm: EXAMPLE.COM

# Server domain
ipa env --server domain realm
# domain: corp.example.com
# realm: CORP.EXAMPLE.COM

# Mismatch - client enrolled to wrong domain

Resolution: Client is enrolled to different IPA domain than intended server. Unenroll client: ipa-client-install --uninstall. Enroll to correct IPA server: ipa-client-install --server=ipa.corp.example.com --domain=corp.example.com --realm=CORP.EXAMPLE.COM. Verify domain matches: ipa env domain should match ipa env --server domain.

xmlrpc_uri Shows HTTP Instead of HTTPS

Symptoms: ipa env xmlrpc_uri shows http:// instead of expected https://.

Diagnosis:

# Check XML-RPC URI
ipa env xmlrpc_uri
# xmlrpc_uri: http://ipa.example.com/ipa/xml (insecure!)

# Check client configuration
cat /etc/ipa/default.conf | grep xmlrpc_uri
# xmlrpc_uri = http://ipa.example.com/ipa/xml

# Manually configured with HTTP - insecure

Resolution: IPA API should always use HTTPS for security. HTTP exposes credentials and data in transit. Remove manual HTTP configuration from /etc/ipa/default.conf: sed -i '/xmlrpc_uri.*http:/d' /etc/ipa/default.conf. Re-enroll client to generate correct HTTPS configuration: ipa-client-install --force-join. Verify: ipa env xmlrpc_uri should show https://.

Commands

env

Usage: ipa [global-options] env [VARIABLES] [options]

Show environment variables.

Arguments

Argument Required Description

VARIABLES no

Options

Option	Description
`--server`	Forward to server instead of running locally

plugins

Usage: ipa [global-options] plugins [options]

Show all loaded plugins.

Options

Option	Description
`--server`	Forward to server instead of running locally

Overview

env - Environment Variables

plugins - Plugin Information

Common Use Cases

Examples

Show All Environment Variables

Show Specific Environment Variables

Compare Client and Server Environment

Verify Server Connectivity

List All Loaded Plugins

Verify Custom Plugin Loaded

Server-Side Plugin Inspection

Debugging API Version Mismatch

Inspecting LDAP Connection URI

Verifying Certificate Authority Status

Development: Checking IPA Mode

Use Cases

1. Diagnosing Client-Server API Version Mismatch

2. Verifying Custom Plugin Installation

3. Identifying Active IPA Server in Multi-Server Deployment

4. Troubleshooting Missing LDAP Connection

5. Verifying IPA Installation Mode for Development

6. Checking Certificate Authority Configuration

7. Inspecting IPA Context for Script Automation

8. Documenting IPA Configuration for Audit

9. Comparing Development and Production Environments

10. Identifying IPA Domain and Realm Configuration

Security Considerations

Information Disclosure via Environment Variables

Plugin Enumeration for Vulnerability Discovery

API Version Exposure

LDAP URI Disclosure

Server Hostname Disclosure

Execution Context Leakage

CA Configuration Disclosure

Debug Mode Detection

Custom Plugin Discovery

Base DN and Domain Disclosure

Environment Variable Command Injection

No Access Control for env/plugins Commands

Troubleshooting

ipa env Returns Different Results Than Expected

ipa env server Shows Unexpected Server

ipa plugins Shows Fewer Plugins Than Expected

Custom Plugin Not Appearing in ipa plugins

API Version Mismatch Error

ipa env Shows in_server: True on Client

ipa env Returns “Connection refused”

ldap_uri Shows Wrong URI Type

enable_ra Shows False When CA Expected

Debugging: verbose Shows 0 When Debug Enabled

env Command Times Out

plugin List Missing Expected Plugins

Client Shows Different domain Than Server

xmlrpc_uri Shows HTTP Instead of HTTPS

Commands

env

Arguments

Options

plugins

Options

Related Topics