HBAC Service Groups
Manage groups of HBAC services for simplified policy management. Service groups enable collective assignment of multiple services to HBAC rules, reducing administrative overhead. Features include nested service group membership, service addition and removal, and centralized management of related service access policies.
HBAC service groups can contain any number of individual services, or “members”. Every group must have a description.
EXAMPLES
Add a new HBAC service group:
ipa hbacsvcgroup-add --desc="login services" loginAdd members to an HBAC service group:
ipa hbacsvcgroup-add-member --hbacsvcs=sshd --hbacsvcs=login loginDisplay information about a named group:
ipa hbacsvcgroup-show loginDelete an HBAC service group:
ipa hbacsvcgroup-del login
Commands
hbacsvcgroup-add
Usage: ipa [global-options] hbacsvcgroup-add NAME [options]
Add a new HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group name |
Options
| Option | Description |
|---|---|
--desc DESC | HBAC service group 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. |
--no-members | Suppress processing of membership attributes. |
hbacsvcgroup-add-member
Usage: ipa [global-options] hbacsvcgroup-add-member NAME [options]
Add members to an HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--hbacsvcs HBACSVCS | HBAC services to add |
hbacsvcgroup-del
Usage: ipa [global-options] hbacsvcgroup-del NAME [options]
Delete an HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group name |
Options
| Option | Description |
|---|---|
--continue | Continuous mode: Don’t stop on errors. |
hbacsvcgroup-find
Usage: ipa [global-options] hbacsvcgroup-find [CRITERIA] [options]
Search for an HBAC service group.
Arguments
Argument Required Description
CRITERIA no A string searched in all relevant object
attributes
Options
| Option | Description |
|---|---|
--name NAME | Service group name |
--desc DESC | HBAC service group 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”) |
hbacsvcgroup-mod
Usage: ipa [global-options] hbacsvcgroup-mod NAME [options]
Modify an HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group name |
Options
| Option | Description |
|---|---|
--desc DESC | HBAC service group 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. |
--no-members | Suppress processing of membership attributes. |
hbacsvcgroup-remove-member
Usage:
ipa [global-options] hbacsvcgroup-remove-member NAME [options]
Remove members from an HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--hbacsvcs HBACSVCS | HBAC services to remove |
hbacsvcgroup-show
Usage: ipa [global-options] hbacsvcgroup-show NAME [options]
Display information about an HBAC service group.
Arguments
| Argument | Required | Description |
|---|---|---|
NAME | yes | Service group 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. |
--no-members | Suppress processing of membership attributes. |
Use Cases
Grouping File Transfer Services for Unified Access Control
Organizations managing multiple file transfer protocols can group related services to apply consistent HBAC policies across FTP, SFTP, and SCP access.
# Create service group for file transfer protocols
ipa hbacsvcgroup-add file-transfer \
--desc="All file transfer service protocols"
# Add file transfer services to group
ipa hbacsvcgroup-add-member file-transfer \
--hbacsvcs=ftp,sftp,vsftpd,ftpd
# Verify group membership
ipa hbacsvcgroup-show file-transfer
# Create HBAC rule using service group instead of individual services
ipa hbacrule-add file_transfer_policy
ipa hbacrule-add-service file_transfer_policy \
--hbacsvcgroups=file-transfer
ipa hbacrule-add-user file_transfer_policy --groups=data-transfer-team
ipa hbacrule-add-host file_transfer_policy --hostgroups=file-servers
Consolidating Remote Access Services for Security Policy
Remote access control requires managing SSH, VPN, and remote desktop services collectively to enforce consistent access policies across all remote entry points.
# Create remote access service group
ipa hbacsvcgroup-add remote-access \
--desc="All remote access and login services"
# Add remote access services
ipa hbacsvcgroup-add-member remote-access \
--hbacsvcs=sshd,login,gdm,xrdp,cockpit
# Create HBAC rule for remote workers
ipa hbacrule-add remote_worker_access
ipa hbacrule-add-service remote_worker_access \
--hbacsvcgroups=remote-access
ipa hbacrule-add-user remote_worker_access --groups=remote-employees
ipa hbacrule-enable remote_worker_access
# Single policy now controls all remote access methods
Creating Privilege Escalation Service Group
Grouping privilege escalation services (su, sudo, polkit) enables centralized control over elevation mechanisms.
# Create privilege escalation group
ipa hbacsvcgroup-add privilege-escalation \
--desc="Services that allow privilege escalation"
# Add escalation services
ipa hbacsvcgroup-add-member privilege-escalation \
--hbacsvcs=su,sudo,su-l
# Create HBAC rule restricting privilege escalation
ipa hbacrule-add admin_escalation
ipa hbacrule-add-service admin_escalation \
--hbacsvcgroups=privilege-escalation
ipa hbacrule-add-user admin_escalation --groups=system-admins
ipa hbacrule-add-host admin_escalation --hostgroups=production-servers
Organizing Database Access Services by Database Type
Large environments with multiple database systems benefit from grouping services by database type for role-based access management.
# Create service group for PostgreSQL services
ipa hbacsvcgroup-add postgresql-services \
--desc="PostgreSQL database access services"
ipa hbacsvcgroup-add-member postgresql-services \
--hbacsvcs=postgresql,psql,pg_admin
# Create separate group for MySQL services
ipa hbacsvcgroup-add mysql-services \
--desc="MySQL database access services"
ipa hbacsvcgroup-add-member mysql-services \
--hbacsvcs=mysql,mysqld,mariadb
# Apply different HBAC policies to each database type
ipa hbacrule-add postgres_dba_access
ipa hbacrule-add-service postgres_dba_access \
--hbacsvcgroups=postgresql-services
ipa hbacrule-add-user postgres_dba_access --groups=postgres-dbas
Removing Services from Groups During Service Decommissioning
When services are retired, removing them from service groups ensures policies no longer apply without modifying HBAC rules.
# Show current group membership
ipa hbacsvcgroup-show legacy-apps
# Remove decommissioned service from group
ipa hbacsvcgroup-remove-member legacy-apps --hbacsvcs=old-ftp
# Verify removal
ipa hbacsvcgroup-show legacy-apps
# HBAC rules referencing legacy-apps group automatically
# no longer apply to old-ftp service
Modifying Service Group Descriptions for Documentation
Clear group descriptions help administrators understand group purpose during policy review and audit activities.
# Update description for clarity
ipa hbacsvcgroup-mod file-transfer \
--desc="File transfer protocols - FTP, SFTP, SCP for data exchange"
# Add compliance reference
ipa hbacsvcgroup-mod database-services \
--desc="Database services - SOX compliance requires restricted access"
# View updated description
ipa hbacsvcgroup-show file-transfer
Finding Service Groups by Criteria for Policy Analysis
Searching service groups by name or description helps identify relevant groups during HBAC policy planning and troubleshooting.
# Find all groups containing "remote"
ipa hbacsvcgroup-find remote
# Search for database-related groups
ipa hbacsvcgroup-find database
# List all service groups for audit
ipa hbacsvcgroup-find --all > service-groups-audit.txt
# Count total service groups
ipa hbacsvcgroup-find | grep "Number of entries returned:"
Deleting Empty Service Groups After Reorganization
Policy reorganization may leave empty service groups that should be removed to maintain clean configuration.
# Check if group has any members
ipa hbacsvcgroup-show test-group
# Verify group not referenced in HBAC rules
ipa hbacrule-find --hbacsvcgroups=test-group
# Delete empty group
ipa hbacsvcgroup-del test-group
# Confirm deletion
ipa hbacsvcgroup-show test-group
# Should return: group not found
Bulk Adding Services to New Service Group
Creating service groups for new application categories requires efficient bulk addition of multiple related services.
# Create new application category group
ipa hbacsvcgroup-add web-applications \
--desc="Web application and API services"
# Add multiple services in single command
ipa hbacsvcgroup-add-member web-applications \
--hbacsvcs=httpd,nginx,tomcat,apache,webapp1,webapp2
# Verify all services added
ipa hbacsvcgroup-show web-applications
# Use in HBAC rule
ipa hbacrule-add web_app_access
ipa hbacrule-add-service web_app_access \
--hbacsvcgroups=web-applications
Standardizing Service Groups Across Development and Production
Maintaining identical service group structures in development and production environments ensures policy consistency during promotion.
# In development environment
ipa hbacsvcgroup-add standard-services \
--desc="Standard organization services"
# Document membership for replication to production
ipa hbacsvcgroup-show standard-services > standard-services-dev.txt
# In production, create matching group
ipa hbacsvcgroup-add standard-services \
--desc="Standard organization services"
# Add same services to production group
ipa hbacsvcgroup-add-member standard-services \
--hbacsvcs=sshd,login,cockpit
Security Considerations
Service Group Modifications Affect All Referencing HBAC Rules
Adding or removing services from a service group immediately affects all HBAC rules that reference the group. A single service addition can unintentionally grant access to many users across multiple hosts if the group is widely used in HBAC policies. Conversely, service removal can break legitimate access without obvious error messages.
Implement change management requiring impact analysis before service group modifications. Document which HBAC rules reference each service group: ipa hbacrule-find --hbacsvcgroups=group-name. Test group changes in non-production before production deployment. Implement notifications alerting HBAC rule owners when referenced service groups change. Consider service groups immutable after creation for critical services, creating new groups instead of modifying.
Empty Service Groups Bypass Intended Access Controls
Service groups with no members create HBAC rules that match no services, potentially allowing unintended access depending on HBAC rule evaluation logic. Empty groups may cause HBAC rules to evaluate differently than expected, either denying all access or granting inappropriate access if rule logic has flaws.
Validate service group membership before using groups in HBAC rules. Implement monitoring detecting empty service groups: ipa hbacsvcgroup-show group-name should list member services. Delete empty groups rather than leaving them in configuration. Document minimum required membership for each service group. Implement validation in wrapper scripts preventing creation of HBAC rules with empty service groups.
Service Group Deletion Without HBAC Rule Update Breaks Policies
Deleting a service group while HBAC rules still reference it causes those rules to fail or evaluate incorrectly. Unlike service deletion which prevents HBAC rules from referencing deleted services, service group deletion may leave HBAC rules pointing to non-existent groups, causing policy failures.
Before deleting service groups, identify dependent HBAC rules: ipa hbacrule-find --hbacsvcgroups=group-name. Update or delete affected HBAC rules before group deletion. Implement service group deprecation process: remove from all rules, wait observation period, then delete. Document deletion in change management with impact analysis. Test HBAC policy after group deletion to verify no access disruptions.
Service Group Descriptions Disclose Infrastructure Details
Service group descriptions may reveal information about application architecture, technology stack, or organizational structure. These descriptions are readable by authenticated users and assist reconnaissance for targeted attacks. Overly detailed descriptions about criticality, compliance requirements, or business function expose valuable intelligence.
Keep descriptions functional and generic rather than architecturally revealing. Avoid technology specifics, version numbers, or compliance scope details. Use consistent naming that does not disclose sensitive purposes. Document sensitive details in secure operational documentation rather than group descriptions. Review descriptions during security audits for information disclosure.
Nested Service Groups Not Supported Creating Complexity
Unlike user groups or host groups, HBAC service groups do not support nesting (groups containing other groups). Organizations accustomed to nested group structures may create complex hierarchies of individual services leading to management overhead. Attempts to add service groups as members of other service groups fail, creating configuration confusion.
Accept that service group nesting is not supported. Use flat service group structures with clear naming conventions. For complex service categories, create multiple non-nested groups with descriptive names. Document service grouping strategy in operational procedures. Consider using naming prefixes to indicate category: web-frontend, web-backend, web-api instead of nested hierarchy.
Service Addition to Multiple Groups Creates Conflicting Policies
A single service can be member of multiple service groups. If those groups are used in HBAC rules with conflicting access policies, evaluation results may be unpredictable. Service appearing in both permissive and restrictive groups complicates access control analysis and troubleshooting.
Document which services belong to which groups and why. Avoid adding services to multiple groups unless clearly needed. When multi-group membership is necessary, carefully review all HBAC rules using those groups for conflicts. Implement policy testing with ipa hbactest covering multi-group scenarios. Use distinct service groups with no member overlap for clearer policy semantics.
Service Group Name Collisions with Service Names
Service group names share a different namespace than service names, but similar naming can cause confusion during HBAC rule creation. An administrator might mistakenly reference a service when intending a group or vice versa, creating incorrect policies.
Establish naming conventions distinguishing groups from services. Use suffixes like -group or prefixes like grp- for service group names. Document naming standards in operational procedures. Validate HBAC rule configuration reviewing both services and service groups referenced. Implement wrapper scripts that clearly differentiate between service and service group additions to rules.
Bulk Service Removal Can Leave Groups Empty Unintentionally
Using --hbacsvcs with multiple comma-separated services in remove-member command can inadvertently remove all services from a group, leaving it empty. Empty groups used in HBAC rules create policy gaps or failures.
Verify current group membership before bulk removals: ipa hbacsvcgroup-show group-name. Remove services incrementally rather than in bulk for critical groups. Implement confirmation prompts for operations removing multiple services. Monitor for empty service groups after bulk operations. Document which services should always remain in critical groups.
Service Group Replication Delays Cause Inconsistent Policies
In multi-server IPA deployments, service group modifications replicate asynchronously. During replication lag, different IPA servers may have different group membership, causing inconsistent HBAC policy enforcement depending on which server evaluates the request.
Implement change management requiring replication verification before announcing group changes. Use ipa-replica-manage list to check replication health. Force replication after critical changes: ipa-replica-manage force-sync. Test HBAC rules on multiple IPA servers after changes. Monitor replication lag and alert on extended delays. Schedule service group modifications during maintenance windows when possible.
Service Groups Without Descriptions Lack Context
Creating service groups without descriptions (--desc) makes policy review and troubleshooting difficult. Future administrators may not understand group purpose, leading to inappropriate use in new HBAC rules or incorrect modifications.
Require descriptions for all service group creation. Implement wrapper scripts enforcing description requirement. Use descriptions documenting group purpose and intended use cases. Review and update descriptions periodically as group usage evolves. Include responsible team or owner in description for accountability.
Service Group Modification Permissions Allow Unauthorized Access Changes
Overly permissive RBAC allowing unauthorized users to modify service groups enables privilege escalation. An attacker with service group modification rights can add sensitive services to groups used in permissive HBAC rules, granting themselves unauthorized access.
Restrict service group modification to highly trusted administrators. Review permission grants: ipa permission-find --type=hbacsvcgroup. Implement custom RBAC limiting who can modify specific service groups. Audit service group modifications in IPA logs. Implement approval workflows for service group changes in critical environments. Use separate administrative roles for service group management vs HBAC rule management.
Service Groups Used in Disabled HBAC Rules Create False Expectations
Service groups may be referenced in disabled HBAC rules. Administrators might modify group membership believing it affects active policies when referenced rules are actually disabled, creating confusion about policy effectiveness.
Before modifying service groups, identify which HBAC rules reference them and verify rule enabled status: ipa hbacrule-show rule-name | grep Enabled. Document which service groups are actively used in enabled rules. Implement monitoring alerting when service groups are only referenced by disabled rules. Clean up disabled HBAC rules periodically to reduce confusion.
Troubleshooting
Service Group Creation Fails with Duplicate Name
Symptom: Attempting to create service group with hbacsvcgroup-add fails with error indicating group name already exists.
Diagnosis: Verify if group already exists: ipa hbacsvcgroup-show group-name. Check for exact name including case and spelling. Review error message for specific conflict indication. List all service groups to identify naming collision: ipa hbacsvcgroup-find.
Resolution: If group exists, use existing group rather than creating duplicate. Modify existing group description if needed: ipa hbacsvcgroup-mod group-name --desc="Updated description". If attempting to recreate deleted group, verify deletion completed and replicated: wait for replication. Choose alternative name if intentionally creating different group with similar purpose. Check for typos in intended group name.
Adding Service to Group Fails with Service Not Found
Symptom: hbacsvcgroup-add-member fails with error indicating one or more specified services do not exist.
Diagnosis: Verify each service exists: ipa hbacsvc-show service-name for each service in add command. Check spelling and case sensitivity of service names. Review error message identifying which specific service not found. List available services: ipa hbacsvc-find.
Resolution: Create missing services before adding to group: ipa hbacsvc-add service-name --desc="Description". Verify exact service name spelling matches existing services. Use comma-separated list for multiple services: --hbacsvcs=svc1,svc2,svc3 without spaces. Remove non-existent services from add command and add only existing services. Check for replication issues if service exists on different IPA server.
Service Group Deletion Fails Due to HBAC Rule References
Symptom: Attempting to delete service group fails with error indicating group is still in use or has dependencies.
Diagnosis: Identify HBAC rules referencing the group: ipa hbacrule-find --hbacsvcgroups=group-name. Review error message for specific dependency information. Check if group has members preventing deletion (typically members don’t block deletion).
Resolution: Remove group from all HBAC rules first: ipa hbacrule-remove-service rule-name --hbacsvcgroups=group-name for each rule. List all rules using group to ensure complete removal. After removing from all rules, retry deletion: ipa hbacsvcgroup-del group-name. Verify deletion successful: ipa hbacsvcgroup-show group-name should return not found.
Service Group Shows No Members After Adding Services
Symptom: After adding services with hbacsvcgroup-add-member, running hbacsvcgroup-show displays group but lists no member services.
Diagnosis: Check command output from add-member for errors or warnings. Verify services actually exist: ipa hbacsvc-show service-name. Review if replication completed: group modification may not have propagated. Test on different IPA server to check for server-specific issue.
Resolution: Verify services were specified correctly: --hbacsvcs=service1,service2 format. Check for command syntax errors: ensure no spaces in comma-separated list. Force replication if needed: ipa-replica-manage force-sync. Retry adding members if initial attempt failed silently. Clear SSSD cache if viewing from client: sss_cache -E. Use --all flag to see complete attribute set: ipa hbacsvcgroup-show group-name --all.
Cannot Remove Service from Group
Symptom: hbacsvcgroup-remove-member command fails or succeeds but service still appears in group membership.
Diagnosis: Verify exact service name: case-sensitive match required. Check if service is actually a member: ipa hbacsvcgroup-show group-name. Review command syntax for errors. Check for replication issues between servers.
Resolution: Use exact service name from show output: copy/paste to avoid typos. Verify command syntax: ipa hbacsvcgroup-remove-member group-name --hbacsvcs=service-name. Wait for replication to complete: check group on different IPA server. Force replication if needed: ipa-replica-manage force-sync. If service persists after removal, check for LDAP replication conflicts: ldapsearch -Y GSSAPI -b "dc=example,dc=com" "(nsds5ReplConflict=*)".
Service Group Description Cannot Be Modified
Symptom: Attempting to change group description with hbacsvcgroup-mod --desc fails with permission error or has no effect.
Diagnosis: Verify user permissions: check admin group membership or HBAC Administrator role. Test syntax: ipa hbacsvcgroup-mod group-name --desc="New description". Check Kerberos authentication: klist for valid ticket. Review if group is system-protected (unlikely for service groups).
Resolution: Ensure user has appropriate permissions: ipa group-add-member admins --users=username. Use correct command syntax with group name and description flag. Renew Kerberos ticket if expired: kinit username. Check IPA logs for specific error: /var/log/httpd/error_log. Test with admin account to isolate permission vs system issue: kinit admin.
Finding Service Groups Returns No Results
Symptom: hbacsvcgroup-find with search criteria returns zero results despite knowing groups exist matching criteria.
Diagnosis: Verify search criteria spelling and case. Check if using CRITERIA argument vs specific flag: CRITERIA searches all attributes. Test with no criteria to list all groups: ipa hbacsvcgroup-find. Verify group exists: ipa hbacsvcgroup-show exact-name.
Resolution: Try different search patterns: partial name, description keywords. Use specific flags: --name=group-name for exact name match. List all service groups to see if desired group appears: ipa hbacsvcgroup-find --all. Check replication if group exists on different server. Clear local cache: sss_cache -E. Verify authenticated and connected to correct IPA server.
Service Group Referenced in HBAC Rule Not Evaluated
Symptom: HBAC rule references service group but hbactest or actual authentication doesn’t evaluate group correctly, reporting service not matched.
Diagnosis: Verify group actually exists: ipa hbacsvcgroup-show group-name. Check group has members: empty groups may cause evaluation issues. Confirm HBAC rule syntax: ipa hbacrule-show rule-name showing servicegroup membership. Test with individual service instead of group to isolate group vs service issue.
Resolution: Ensure group contains relevant services: ipa hbacsvcgroup-show group-name should list member services. Verify HBAC rule uses correct group reference: ipa hbacrule-show rule-name --all. Add missing services to group if needed. Clear SSSD cache on client: sss_cache -E && systemctl restart sssd. Test HBAC evaluation: ipa hbactest --service=service-name --user=username --host=hostname. Force replication to ensure group definition propagated: ipa-replica-manage force-sync.
Bulk Service Addition Partially Fails
Symptom: Adding multiple services to group with comma-separated --hbacsvcs list partially succeeds; some services added but others fail.
Diagnosis: Review command output carefully: shows which services succeeded and which failed. Identify failed services from error messages. Verify failed services exist: ipa hbacsvc-show service-name for each failed service.
Resolution: Create missing services first: ipa hbacsvc-add failed-service --desc="Description". Retry adding previously failed services: ipa hbacsvcgroup-add-member group-name --hbacsvcs=failed-svc1,failed-svc2. Verify final group membership: ipa hbacsvcgroup-show group-name. For systematic management, add services individually instead of bulk for better error handling.
Service Group Membership Not Replicating
Symptom: Service group membership changes on one IPA server not visible on replica servers.
Diagnosis: Check replication status: ipa-replica-manage list for errors. Verify modification on source server: ipa hbacsvcgroup-show group-name on server where change was made. Compare with other replicas: run same command on each replica. Review replication lag timing.
Resolution: Wait for normal replication: typically 30-60 seconds. Force replication if needed: ipa-replica-manage force-sync --from=source.example.com. Verify replication health: check for ongoing replication errors. Restart IPA services on affected replica if replication stuck: ipactl restart. Check for LDAP replication conflicts and resolve: ldapsearch -Y GSSAPI -b "dc=example,dc=com" "(nsds5ReplConflict=*)".
Empty Service Group After Removing All Members
Symptom: After removing last service from group, group exists but has no members, potentially causing HBAC policy issues.
Diagnosis: Verify group membership: ipa hbacsvcgroup-show group-name shows no members. Check if group is referenced in HBAC rules: ipa hbacrule-find --hbacsvcgroups=group-name. Determine if empty group was intentional or accidental.
Resolution: If group should have members, add intended services: ipa hbacsvcgroup-add-member group-name --hbacsvcs=service1,service2. If group no longer needed, delete it after removing from HBAC rules. If keeping empty group temporarily, document reason and schedule remediation. Update HBAC rules to not use empty groups: remove group from rules or add services to group. Monitor for empty service groups as operational issue.
Service Group Name Too Long for Creation
Symptom: Creating service group fails with name length validation error.
Diagnosis: Count characters in proposed group name. Review error message for maximum length constraint. Compare against successfully created groups with shorter names.
Resolution: Abbreviate group name while maintaining clarity and uniqueness. Use meaningful abbreviations documented in description: --desc="Full Name Explanation". Establish naming conventions accommodating length limits. Test abbreviated name before production use. Document naming standards preventing future length issues.
Permission Denied When Viewing Service Group
Symptom: hbacsvcgroup-show fails with insufficient access or permission denied error.
Diagnosis: Verify Kerberos authentication: klist for valid ticket. Check user permissions and role assignments: ipa user-show $(whoami) --all. Test if issue is specific to one group or all groups. Try with admin account to isolate permission vs existence issue.
Resolution: Authenticate if no ticket: kinit username. For read access, most authenticated users should be able to view service groups. If denied, check custom ACIs restricting access: ipa permission-find --type=hbacsvcgroup. Use admin account for troubleshooting: kinit admin && ipa hbacsvcgroup-show group-name. Verify group actually exists: may get permission error for wrong name. Contact IPA administrators if legitimate access blocked by custom permissions.
Service Group Modification Not Reflected in HBAC Test
Symptom: After modifying service group membership, hbactest still shows old group configuration.
Diagnosis: Check when modification was made vs when test executed: replication lag possible. Verify modification succeeded: ipa hbacsvcgroup-show group-name should show updated membership. Test on same IPA server where modification was made. Review SSSD cache on client if testing from client system.
Resolution: Wait for replication to complete: typically under 1 minute. Force replication: ipa-replica-manage force-sync. Clear SSSD cache: sss_cache -E && systemctl restart sssd. Verify hbactest using current data: run on IPA server directly. Re-run hbactest after confirming replication: ipa hbactest --service=service-name --user=username --host=hostname. Check for cached test results in administrative tools.