IPA Locations

Overview

IPA locations provide DNS-based service discovery and client affinity for geographically distributed FreeIPA deployments. Locations enable IPA clients to automatically discover and prefer nearby IPA servers (KDCs, LDAP servers, certificate authorities) based on their physical or network location, reducing cross-site authentication traffic and improving performance.

Locations integrate with IPA’s DNS infrastructure to automatically update DNS SRV (service) record priorities based on server-to-location assignments. When a client performs DNS SRV lookups for IPA services (e.g., _kerberos._udp.example.com), DNS returns IPA servers assigned to the client’s location with higher priority, causing clients to prefer local servers over remote ones.

Key Concepts

Location: A named entity representing a physical site, datacenter, office, or network segment (e.g., “new-york”, “london-dc”, “us-east-1”).

Server Assignment: IPA servers (replicas) are assigned to locations using ipa server-mod --location=<name>. A server can belong to only one location.

DNS SRV Records: IPA automatically maintains DNS SRV records for Kerberos (_kerberos, _kerberos-master, _kpasswd), LDAP (_ldap), and other services. SRV records include priority values that determine which servers clients prefer.

Priority Assignment: Servers in the client’s location receive lower priority values (higher preference) in DNS SRV records. Servers in other locations receive higher priority values (lower preference), serving as backups.

Client Location Detection: Clients determine their location through DNS-based mechanisms (DNS search domain, subnet-based location records) or explicit configuration.

Benefits

Reduced latency: Clients authenticate to nearby KDCs rather than crossing WAN links, improving login speed.

Bandwidth optimization: LDAP queries, certificate requests, and Kerberos authentication stay within the local site when local replicas are available.

Automatic failover: If all local servers are unavailable, clients automatically fall back to servers in other locations based on SRV priority.

Simplified client configuration: No manual server specification required. Clients use DNS SRV lookups to discover appropriate servers automatically.

Multi-site topolo gy support: Enables IPA to span multiple datacenters or geographic regions while maintaining optimal client-server affinity.

How It Works

1. Location creation: Administrator creates locations representing sites: ipa location-add new-york
2. Server assignment: Servers are assigned to locations: ipa server-mod ipa01.example.com --location=new-york
3. DNS SRV update: IPA’s DNS infrastructure automatically updates SRV records with location-based priorities
4. Client discovery: Client performs DNS SRV lookup (e.g., dig +short SRV _kerberos._udp.example.com)
5. Priority-based selection: Client receives list of servers sorted by priority, with local servers first
6. Service connection: Client connects to highest-priority (lowest value) server available

Integration with DNS

IPA locations require IPA-managed DNS (ipa-dns-install). Locations do not function with external DNS servers unless administrators manually implement location-aware SRV records.

When a server is assigned to a location, IPA’s DNS plugin recalculates SRV record priorities:

• Servers in the same location as the client: priority 0 (highest preference)
• Servers in other locations: priority 50 (lower preference)
• Servers without location assignment: priority 100 (lowest preference)

Clients without a location assignment receive all servers with equal priority.

Location Detection

Clients determine their location through:

DNS search domain: Client’s DNS search domain may indicate location (e.g., ny.example.com → “new-york” location)

Subnet-based records: IPA DNS can publish location information based on client IP subnet (advanced configuration)

Explicit configuration: Clients can have location explicitly configured in /etc/ipa/default.conf (not typical)

In most deployments, location detection is automatic through DNS infrastructure.

Examples

Find all locations:

ipa location-find

Show specific location:

ipa location-show location

Add location:

ipa location-add location --description 'My location'

Delete location:

ipa location-del location

Use Cases

1. Multi-Datacenter Deployment with Location-Based Affinity

Organization operates IPA deployment across three datacenters (New York, London, Tokyo). Each datacenter has IPA replicas, and clients should prefer local replicas for authentication.

# Create locations for each datacenter
ipa location-add new-york --description="New York Datacenter"
ipa location-add london --description="London Datacenter"
ipa location-add tokyo --description="Tokyo Datacenter"

# Assign New York servers to new-york location
ipa server-mod ipa01.example.com --location=new-york
ipa server-mod ipa02.example.com --location=new-york

# Assign London servers to london location
ipa server-mod ipa-lon01.example.com --location=london
ipa server-mod ipa-lon02.example.com --location=london

# Assign Tokyo servers to tokyo location
ipa server-mod ipa-tyo01.example.com --location=tokyo

# Verify location assignments
ipa location-show new-york
# Output shows which servers are assigned

# DNS SRV records now prioritize local servers
# Client in New York performing DNS lookup:
dig +short SRV _kerberos._udp.example.com
# Returns:
# 0 100 88 ipa01.example.com.
# 0 100 88 ipa02.example.com.
# 50 100 88 ipa-lon01.example.com.
# 50 100 88 ipa-lon02.example.com.
# 50 100 88 ipa-tyo01.example.com.

Result: Clients in each datacenter automatically prefer local IPA servers (priority 0) while maintaining failover to other datacenters (priority 50) if local servers are unavailable.

2. Adding New Datacenter to Existing Deployment

Organization expands to new office in Singapore and needs to add IPA replicas with automatic client affinity.

# Install new IPA replica in Singapore
# (On singapore-01.example.com)
ipa-replica-install

# Create Singapore location
ipa location-add singapore --description="Singapore Office"

# Assign new replica to Singapore location
ipa server-mod singapore-01.example.com --location=singapore

# Install second replica for redundancy
# (On singapore-02.example.com)
ipa-replica-install

# Assign second replica to location
ipa server-mod singapore-02.example.com --location=singapore

# Verify location configuration
ipa location-show singapore --all

# Clients in Singapore network now automatically discover local servers
# No client configuration changes required

Result: New Singapore clients automatically discover and prefer local replicas. Existing clients in other locations remain unaffected. No client reconfiguration needed.

3. Optimizing Cross-Site Replication Topology

Using locations to identify which servers should have direct replication agreements to minimize cross-WAN replication traffic.

# List all locations and their assigned servers
ipa location-find

# For each location, ensure intra-location replication
# New York servers should replicate to each other
ipa topologysegment-find
# Verify ipa01.example.com ↔ ipa02.example.com segment exists

# Minimize cross-location segments
# Create single bridge between datacenters
ipa topologysegment-add domain --name=ny-to-london \
  --leftnode=ipa02.example.com \
  --rightnode=ipa-lon01.example.com

ipa topologysegment-add domain --name=london-to-tokyo \
  --leftnode=ipa-lon02.example.com \
  --rightnode=ipa-tyo01.example.com

# Remove unnecessary cross-site segments
ipa topologysegment-del domain ny-to-tokyo

Result: Replication topology optimized for location awareness. Intra-location replication is fast (local LAN), while cross-location replication minimized to necessary bridges, reducing WAN bandwidth consumption.

4. Diagnosing Client Location Affinity Issues

Client in London office is authenticating to New York servers instead of local London servers, causing slow logins.

# On London client, check DNS SRV resolution
dig +short SRV _kerberos._udp.example.com
# Expected: London servers with priority 0
# Actual: All servers with priority 50 (location not detected)

# Verify London servers are assigned to location
ipa location-show london
# Check "Servers" list includes london servers

# Check server location assignment
ipa server-show ipa-lon01.example.com | grep Location
# Should show: Location: london

# Verify client's DNS search domain
cat /etc/resolv.conf
# May show: search example.com (no location indicator)

# Check IPA client configuration
cat /etc/ipa/default.conf | grep location
# If not set, client location is auto-detected via DNS

# Test DNS resolution from client
host -t SRV _kerberos._udp.london.example.com
# If location-specific DNS zone exists

# Check SSSD location detection
sssctl domain-status example.com
# Look for "IPA location" field

Resolution: Client’s DNS search domain didn’t indicate location. Either configure DNS-based location detection or set explicit location in client configuration.

5. Decommissioning Datacenter and Migrating Clients

Organization is closing Tokyo datacenter and migrating all Tokyo clients to Singapore datacenter.

# Verify Tokyo location and assigned servers
ipa location-show tokyo
# Servers: ipa-tyo01.example.com

# Create Singapore location (if not exists)
ipa location-add singapore --description="Singapore Datacenter"

# Install new Singapore replicas
# (On singapore-01.example.com and singapore-02.example.com)
ipa-replica-install

# Assign Singapore replicas to location
ipa server-mod singapore-01.example.com --location=singapore
ipa server-mod singapore-02.example.com --location=singapore

# Update client DNS configuration to use Singapore DNS servers
# (Via DHCP or network reconfiguration)
# Clients will now resolve Singapore servers as local

# Remove Tokyo server from replication topology
ipa topologysegment-del domain tokyo-to-london

# Uninstall Tokyo replica
ipa server-del ipa-tyo01.example.com

# Delete Tokyo location (now empty)
ipa location-del tokyo

# Verify no references remain
ipa location-find

Result: Tokyo datacenter decommissioned cleanly. Clients migrated to Singapore location now use Singapore replicas. Tokyo location removed from IPA configuration.

6. Testing Location Configuration Before Production

Administrator wants to test location-based service discovery without affecting production clients.

# Create test location
ipa location-add test-lab --description="Testing Lab"

# Deploy test IPA replica
# (On test-ipa.example.com)
ipa-replica-install

# Assign test replica to test location
ipa server-mod test-ipa.example.com --location=test-lab

# On test client, override location detection
echo "location = test-lab" >> /etc/ipa/default.conf

# Restart SSSD to apply location
systemctl restart sssd

# Verify client is using test location
sssctl domain-status example.com | grep "IPA location"
# Should show: IPA location: test-lab

# Test authentication uses test replica
kinit testuser
# Check KDC server used
klist -v | grep "KDC"
# Should show: test-ipa.example.com

# After successful testing, remove test location override
sed -i '/location = test-lab/d' /etc/ipa/default.conf
systemctl restart sssd

Result: Test location created and validated without affecting production clients. Test replica isolated for safe experimentation.

7. Viewing DNS SRV Priority Changes After Location Assignment

Administrator assigns server to location and wants to verify DNS SRV records updated correctly.

# Before location assignment
dig +short SRV _kerberos._udp.example.com
# All servers have same priority:
# 50 100 88 ipa01.example.com.
# 50 100 88 ipa02.example.com.
# 50 100 88 ipa03.example.com.

# Create location and assign server
ipa location-add boston --description="Boston Office"
ipa server-mod ipa01.example.com --location=boston

# Wait for DNS propagation (typically immediate)
# Check DNS SRV records again
dig +short SRV _kerberos._udp.boston.example.com
# Location-specific zone may exist

# Check global SRV record from Boston client perspective
dig +short SRV _kerberos._udp.example.com
# ipa01.example.com now has priority 0 for Boston clients:
# 0 100 88 ipa01.example.com.
# 50 100 88 ipa02.example.com.
# 50 100 88 ipa03.example.com.

# Verify all service types updated
dig +short SRV _ldap._tcp.example.com
dig +short SRV _kerberos-master._udp.example.com
dig +short SRV _kpasswd._udp.example.com
# All should show location-based priorities

Result: DNS SRV records automatically updated to reflect location-based priorities. Clients in Boston location now prefer ipa01.example.com for all IPA services.

8. Handling Servers Without Location Assignment

Some servers are intentionally not assigned to locations (e.g., central management servers, backup servers) and should be deprioritized for client use.

# View all servers and their location assignments
ipa server-find --all | grep -E "Server name|Location"

# Servers without location assignment:
# ipa-backup.example.com: (no location)

# These servers receive lowest priority in DNS SRV
dig +short SRV _kerberos._udp.example.com
# 0 100 88 ipa01.example.com. (location: new-york, from NY client)
# 50 100 88 ipa-lon01.example.com. (location: london)
# 100 100 88 ipa-backup.example.com. (no location)

# Intentionally leave backup servers without location
# Clients only use them if all location-assigned servers fail

# Verify backup server is still in replication topology
ipa topologysegment-find | grep ipa-backup
# Ensure replication agreements exist

Result: Servers without location assignment serve as last-resort backups with lowest DNS SRV priority (100). Used only when all location-specific servers are unavailable.

9. Auditing Location Configuration Across Deployment

Security audit requires documenting which servers are assigned to which locations and verifying configuration matches network topology.

# Generate location-to-server mapping report
for loc in $(ipa location-find --pkey-only | grep 'Location name:' | awk '{print $3}'); do
  echo "=== Location: $loc ==="
  ipa location-show "$loc" | grep -E "Location name|Description|Servers"
  echo ""
done

# List servers without location assignment
ipa server-find --all | grep -B1 "Location:" | grep -B1 "^\s*$" | grep "Server name" | awk '{print $3}'

# Verify each server's physical location matches assigned location
# Compare with network documentation/CMDB

# Check for location assignment errors
# Example: Server in NYC datacenter assigned to London location
ipa server-show ipa-nyc03.example.com | grep Location
# Location: london ← ERROR: Should be new-york

# Correct misassigned server
ipa server-mod ipa-nyc03.example.com --location=new-york

# Export location configuration for documentation
ipa location-find --all > /var/log/ipa-locations-audit-$(date +%Y%m%d).txt

Result: Comprehensive audit of location configuration completed. Misassigned servers identified and corrected. Documentation generated for compliance.

10. Removing Location Assignment from Server

Server is being repurposed as a generic backup replica and should no longer be location-specific.

# Check current location assignment
ipa server-show ipa05.example.com | grep Location
# Location: new-york

# Remove location assignment
ipa server-mod ipa05.example.com --location=""

# Verify location removed
ipa server-show ipa05.example.com | grep Location
# Location: (empty/not shown)

# Check DNS SRV priority updated
dig +short SRV _kerberos._udp.example.com
# ipa05.example.com now has priority 100 (no location)

# Verify server still in topology
ipa topologysegment-find | grep ipa05
# Replication agreements should still exist

# Server now serves as backup for all locations

Result: Location assignment removed from server. Server now deprioritized in DNS SRV records (priority 100) and serves as backup for all locations rather than preferred server for specific location.

Security Considerations

Location Visibility and Information Disclosure

IPA locations are visible to all authenticated users by default. Location names and descriptions may reveal internal network topology, datacenter locations, or organizational structure. Avoid using sensitive naming schemes that disclose confidential infrastructure information. For example, use “location-01” instead of “secret-military-base-colorado”. Location metadata is not protected by RBAC in default configurations, and any authenticated user can enumerate locations using ipa location-find.

DNS SRV Record Manipulation

DNS-based service discovery relies on the integrity of DNS SRV records. If an attacker gains control of IPA’s DNS infrastructure (via compromised IPA server or DNS zone manipulation), they could modify SRV records to redirect clients to malicious servers impersonating IPA services. This could enable Kerberos credential theft, LDAP data exfiltration, or man-in-the-middle attacks. Protect IPA DNS infrastructure with strong access controls, DNSSEC (if feasible), and monitor for unauthorized DNS record modifications. Limit dns-admin role assignment to trusted administrators only.

Client Location Spoofing

If client location detection relies solely on DNS search domains or IP subnet detection, clients may be able to spoof their location by modifying /etc/resolv.conf or /etc/ipa/default.conf. This could allow clients to bypass network segmentation controls or access servers in unauthorized locations. For environments where location-based access control is critical, implement network-layer controls (firewalls, network segmentation) to enforce location boundaries rather than relying solely on DNS-based location detection. Location is a client affinity mechanism, not a security boundary.

Cross-Location Replication Traffic Exposure

When IPA replicas in different locations replicate over WAN links, replication traffic may traverse untrusted networks (Internet, third-party networks). IPA replication uses LDAP over TLS and Kerberos, providing encryption in transit, but ensure network paths between locations are adequately secured. Use VPNs, dedicated circuits, or encrypted tunnels for cross-location replication traffic. Monitor replication agreements for unusual traffic patterns that may indicate data exfiltration attempts.

Location Deletion with Assigned Servers

Deleting a location that still has servers assigned may cause unexpected DNS SRV priority changes. Servers previously assigned to the deleted location revert to “no location” status, receiving priority 100 (lowest preference). This could disrupt client service discovery if clients were relying on those servers as their local high-priority servers. Before deleting a location, reassign all servers to different locations or verify that no production clients depend on the location-based affinity for those servers.

Unbalanced Location Assignments

If location assignments are unbalanced (e.g., 10 servers in new-york location, 1 server in london location), clients in under-served locations may experience performance degradation or single points of failure. While this is primarily an availability concern, it can become a security issue if clients fail over to distant locations during local server outages, potentially exposing authentication traffic to different network segments or compliance zones. Ensure each location has sufficient redundancy (minimum 2 replicas recommended) to maintain security boundaries during server failures.

Implicit Trust in Location-Based Priority

Administrators may incorrectly assume that location-based DNS SRV priority provides access control (e.g., “London clients cannot reach New York servers”). This is false—locations only influence client preference via DNS priority, not access control. Clients can still connect to any IPA server in any location if they override DNS SRV priorities or explicitly specify server hostnames. Implement HBAC rules, firewall rules, or network segmentation for actual access control. Locations are for optimization, not security enforcement.

Location Name Collisions and Confusion

Using ambiguous or overlapping location names (e.g., “east” for both US East and APAC East regions) may cause configuration errors where servers are assigned to wrong locations. This could result in clients using geographically distant servers, increasing latency and potentially routing traffic through unintended network paths. Use unambiguous, hierarchical location naming schemes (e.g., “us-east”, “apac-east”, “eu-west”) and document location naming conventions in operational procedures.

DNS Cache Poisoning for Location Detection

Client location detection via DNS mechanisms (search domains, SRV lookups) is vulnerable to DNS cache poisoning attacks. An attacker who can poison a client’s DNS cache could cause the client to believe it’s in a different location, directing it to attacker-controlled servers or causing denial of service by directing clients to distant servers. Implement DNSSEC where possible to protect DNS integrity, and ensure clients use trusted DNS resolvers (IPA’s integrated DNS or trusted internal DNS servers) rather than public or untrusted DNS.

Audit Log Gaps for Location Changes

Location assignments and modifications are logged in IPA audit logs, but correlating location changes with resulting DNS SRV record changes and client behavior may be challenging. An attacker with administrative access could modify location assignments to redirect clients without obvious audit trail indicating client-level impact. Implement monitoring that correlates location changes (ipa location-mod, ipa server-mod --location) with DNS SRV record changes and client authentication patterns to detect malicious location manipulation.

Insufficient Location-Based Monitoring

Organizations may monitor overall IPA authentication success/failure rates but lack per-location visibility. This prevents detection of location-specific attacks, outages, or misconfigurations. For example, if all London servers are compromised or misconfigured, London clients may fail over to New York servers, masking the London location issue. Implement per-location monitoring dashboards tracking authentication rates, failures, and client-server affinity to detect location-specific anomalies.

Troubleshooting

Location Not Appearing in ipa location-find

Symptoms: After creating location with ipa location-add, location does not appear in ipa location-find output.

Diagnosis:

# Verify location was created successfully
ipa location-add boston --description="Boston Office"
# Check for success message

# Search for location by name
ipa location-show boston

# Check if location exists but is filtered
ipa location-find --all

Resolution: If ipa location-add returned success but location doesn’t appear, check for replication delays (multi-master environment). Wait 30-60 seconds for replication to complete, then retry ipa location-find. If still missing, check IPA logs for errors: journalctl -u ipa -n 100. Verify administrator has permissions to create locations.

Server Location Assignment Not Updating DNS SRV Records

Symptoms: Assigned server to location using ipa server-mod --location=<name>, but DNS SRV records still show old priorities.

Diagnosis:

# Verify location assignment succeeded
ipa server-show ipa01.example.com | grep Location
# Should show new location

# Check DNS SRV records
dig +short SRV _kerberos._udp.example.com
# Look for priority changes

# Verify IPA DNS is being used (not external DNS)
ipa dns-is-enabled
# Should return: DNS is enabled

# Check DNS server status
systemctl status named-pkcs11

Resolution: DNS SRV record updates should be immediate when using IPA-managed DNS. If records are not updating, restart IPA DNS: systemctl restart named-pkcs11. If using external DNS, IPA cannot automatically update SRV records—you must manually update external DNS configuration to reflect location-based priorities. Verify DNS zone is writable: ipa dnszone-show example.com | grep "Dynamic update".

Client Not Using Location-Preferred Servers

Symptoms: Client performs DNS SRV lookup and receives correct priority-ordered servers, but still connects to distant servers instead of local ones.

Diagnosis:

# On client, verify DNS SRV resolution
dig +short SRV _kerberos._udp.example.com
# Check if local servers have priority 0

# Check SSSD configuration for server override
grep server /etc/sssd/sssd.conf
# If "ipa_server" is set, SSSD ignores DNS SRV

# Check ipa-client-install overrides
grep server /etc/ipa/default.conf
# Should not have "server" or "xmlrpc_uri" hardcoded

# Test SSSD's service discovery
sssctl domain-status example.com
# Look for "Active servers" and "Discovered servers"

# Check if client location is detected
sssctl domain-status example.com | grep "IPA location"

Resolution: If ipa_server is explicitly set in /etc/sssd/sssd.conf, SSSD bypasses DNS SRV discovery. Remove explicit server configuration: sed -i '/ipa_server/d' /etc/sssd/sssd.conf and restart SSSD: systemctl restart sssd. Client will now use DNS SRV discovery with location-based priorities. For clients that must hardcode servers, manually configure them with local servers only.

Cannot Delete Location with “This entry is being referenced”

Symptoms: Attempting to delete location fails with “This entry is being referenced by other entries” error.

Diagnosis:

# Check which servers are assigned to location
ipa location-show boston
# Look for "Servers" list

# Find all servers in location
ipa server-find --all | grep -B5 "Location: boston"

Resolution: Servers must be reassigned or have location removed before deleting location. For each server in location: ipa server-mod ipa01.example.com --location="" (empty string removes assignment) or ipa server-mod ipa01.example.com --location=new-location. After all servers reassigned, retry ipa location-del boston.

Location Shows No Servers Despite Assignment

Symptoms: Server assigned to location, but ipa location-show <location> does not list server in “Servers” field.

Diagnosis:

# Verify server location assignment
ipa server-show ipa01.example.com --all | grep location

# Verify location exists
ipa location-show boston --all

# Check for replication delay
# Wait 1-2 minutes and retry

# Check IPA logs for errors
journalctl -u ipa | grep -i "location\|ipa01"

Resolution: This may indicate a replication or referential integrity issue. Verify server name matches exactly (case-sensitive). Remove and re-add location assignment: ipa server-mod ipa01.example.com --location="" then ipa server-mod ipa01.example.com --location=boston. If issue persists, check LDAP replication status: ipa-replica-manage list and ipa-replica-manage list-ruv. Force replication: ipa-replica-manage force-sync --from=<master-server>.

DNS SRV Queries Return No Results

Symptoms: dig SRV _kerberos._udp.example.com returns NXDOMAIN or no SRV records.

Diagnosis:

# Verify DNS zone exists
ipa dnszone-show example.com

# Check if SRV records exist in zone
ipa dnsrecord-find example.com --name=_kerberos._udp
ipa dnsrecord-find example.com --name=_kerberos._tcp

# Verify named-pkcs11 is running
systemctl status named-pkcs11

# Check DNS forwarding
ipa dnsconfig-show | grep "Forward policy"

# Test DNS from IPA server itself
dig @localhost SRV _kerberos._udp.example.com

Resolution: If SRV records don’t exist, IPA DNS plugin may not be functioning. Restart IPA services: ipactl restart. If still missing, manually trigger SRV record creation: ipa server-mod ipa01.example.com --location=<location> (reassigning triggers DNS update). If DNS zone is externally managed, IPA cannot create SRV records—use external DNS provider’s tools to create location-aware SRV records manually.

Clients in Different Locations Receive Same DNS SRV Priorities

Symptoms: All clients receive identical DNS SRV priorities regardless of their location.

Diagnosis:

# Verify locations are configured and servers assigned
ipa location-find
ipa server-find --all | grep -E "Server name|Location"

# Check if client location is detected
# On client:
sssctl domain-status example.com | grep "IPA location"

# Verify client DNS configuration
cat /etc/resolv.conf
# Check search domain indicates location

Resolution: Client location detection may not be configured. IPA determines client location based on DNS infrastructure (search domains, subnet-based location records). If clients cannot auto-detect location, all clients receive the same global DNS SRV priorities. Implement location-aware DNS (e.g., split-horizon DNS with location-specific search domains: boston.example.com vs london.example.com) or explicitly configure client location in /etc/ipa/default.conf with location = <name>.

Location Assignment Causes Replication Topology Disconnect

Symptoms: After assigning servers to locations, replication agreements break or topology segments become disconnected.

Diagnosis:

# Verify replication topology
ipa topologysegment-find domain
ipa topologysegment-find ca

# Check for disconnected servers
ipa-replica-manage list --verbose
# Look for "replication agreement not found"

# Check replication status
ipa-replica-manage list-ruv

Resolution: Location assignment does not modify replication topology, but if administrators manually adjusted topology segments based on locations and created disconnects, replication will fail. Ensure every server has at least one replication agreement connecting it to the topology. Add missing segments: ipa topologysegment-add domain --name=segment-name --leftnode=server1 --rightnode=server2. Verify connectivity graph is fully connected (no isolated servers).

Permission Denied When Modifying Location

Symptoms: User receives “Insufficient access” error when attempting to create, modify, or delete locations.

Diagnosis:

# Check user's permissions
ipa user-show currentuser --all | grep memberof

# Check location-related permissions
ipa permission-find --name="*location*"

# Verify user has admin privileges
ipa group-show admins --all | grep member

Resolution: Location management requires administrative privileges. Add user to admins group: ipa group-add-member admins --users=alice. Alternatively, create custom RBAC role with location management permissions and assign to user. Standard location permissions: “System: Add Location”, “System: Modify Location”, “System: Remove Location”, “System: Read Location”.

Location Description Contains Special Characters Causing Errors

Symptoms: Location creation or modification fails with parsing errors when description contains special characters.

Diagnosis:

# Try creating location with special description
ipa location-add test --description="Location's \"Office\" & More"
# May fail with quote escaping issues

# Check existing descriptions
ipa location-find --all

Resolution: Use single quotes to wrap descriptions containing special characters: ipa location-add test --description='Location'"'"'s "Office" & More'. Alternatively, avoid special characters in descriptions or use --setattr for complex descriptions: ipa location-add test --setattr=description="Location's Office". Escape special characters according to shell quoting rules.

DNS SRV Weight and Port Values Incorrect

Symptoms: DNS SRV records have unexpected weight or port values that don’t match IPA service ports.

Diagnosis:

# Check DNS SRV record details
dig SRV _kerberos._udp.example.com
# Format: priority weight port target
# Example: 0 100 88 ipa01.example.com.
#          ^  ^   ^
#        prio wt port

# Verify expected ports
# Kerberos: 88, LDAP: 389, LDAPS: 636, Kpasswd: 464

# Check IPA DNS records directly
ipa dnsrecord-show example.com _kerberos._udp

Resolution: SRV record format is priority weight port target. Weight is typically 100 (equal load distribution among same-priority servers). Port should match service: Kerberos (88), LDAP (389), LDAPS (636). If incorrect, IPA DNS plugin may have malfunctioned. Delete and recreate SRV record: ipa dnsrecord-del example.com _kerberos._udp (only if you’re confident), then restart IPA: ipactl restart to regenerate. Safer: verify IPA services are listening on correct ports: ss -tlnp | grep -E '88|389|636|464'.

Client Location Detection Inconsistent

Symptoms: Same client sometimes detected as different locations or no location across authentication attempts.

Diagnosis:

# Check DNS resolution consistency
for i in {1..10}; do
  sssctl domain-status example.com | grep "IPA location"
done
# Should show consistent location

# Check DNS search domain stability
for i in {1..10}; do
  grep search /etc/resolv.conf
done
# Should be consistent

# Check if DHCP is changing DNS configuration
journalctl -u NetworkManager | grep resolv.conf

Resolution: Inconsistent location detection indicates DNS configuration is changing (DHCP updates, NetworkManager interference, VPN connection/disconnection). Configure static DNS search domain in /etc/resolv.conf or NetworkManager connection profile. Alternatively, explicitly set client location in /etc/ipa/default.conf: location = boston, then restart SSSD. This overrides automatic detection with static configuration.

Location-Based Affinity Not Working with External DNS

Symptoms: Organization uses external DNS (not IPA-managed DNS), and location-based service discovery does not function.

Diagnosis:

# Check if IPA DNS is enabled
ipa dns-is-enabled
# May return: DNS is not enabled

# Verify DNS server being used
grep nameserver /etc/resolv.conf
# May point to external DNS (e.g., 8.8.8.8, corporate DNS)

# Check if SRV records exist in external DNS
dig @external-dns-server SRV _kerberos._udp.example.com

Resolution: IPA locations require IPA-managed DNS to automatically update SRV record priorities. With external DNS, you must manually implement location-aware SRV records in the external DNS infrastructure. Options: (1) Migrate to IPA-managed DNS (ipa-dns-install), (2) Manually create location-specific DNS zones in external DNS with appropriate SRV priorities, (3) Use split-horizon DNS where clients in each location use location-specific DNS servers with custom SRV records. Location-based automatic service discovery is not supported with external DNS.

All Servers Show Priority 50 Despite Location Assignment

Symptoms: After configuring locations, DNS SRV queries show all servers with priority 50 instead of expected 0 for local servers.

Diagnosis:

# Verify servers are assigned to locations
ipa server-find --all | grep -E "Server name|Location"

# Check client's detected location
sssctl domain-status example.com | grep "IPA location"
# May show: IPA location: (not set)

# Check if client's search domain maps to location
grep search /etc/resolv.conf

Resolution: Priority 0 is assigned only when client’s location matches server’s location. If client has no detected location, all servers appear with equal priority (50). Configure client location detection via DNS search domains (e.g., clients in Boston use boston.example.com search domain) or explicitly set client location: echo "location = boston" >> /etc/ipa/default.conf && systemctl restart sssd. After client location is set, DNS SRV lookups will show local servers with priority 0.

Commands

location-add

Usage: ipa [global-options] location-add NAME [options]

Add a new IPA location.

Arguments

Argument	Required	Description
NAME	yes	IPA location name

Options

Option	Description
--description DESCRIPTION	IPA Location 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
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

location-del

Usage: ipa [global-options] location-del NAME [options]

Delete an IPA location.

Arguments

Argument	Required	Description
NAME	yes	IPA location name

Options

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

location-find

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

Search for IPA locations.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--name NAME	IPA location name
--description DESCRIPTION	IPA Location description
--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 (“name”)

location-mod

Usage: ipa [global-options] location-mod NAME [options]

Modify information about an IPA location.

Arguments

Argument	Required	Description
NAME	yes	IPA location name

Options

Option	Description
--description DESCRIPTION	IPA Location 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
--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.

location-show

Usage: ipa [global-options] location-show NAME [options]

Display information about an IPA location.

Arguments

Argument	Required	Description
NAME	yes	IPA location 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.